draft-ietf-rap-access-bind-00.txt   draft-ietf-rap-access-bind-01.txt 
Internet Engineering Task Force Walter Weiss Internet Engineering Task Force Walter Weiss
RAP Working Group Ellacoya Networks RAP Working Group Ellacoya Networks
Expiration: February 2002 John Vollbrecht Expiration: October 2002 John Vollbrecht
draft-ietf-rap-access-bind-00.txt David Spence draft-ietf-rap-access-bind-01.txt David Spence
David Rago David Rago
InterLink Networks InterLink Networks
Cees de Laat Cees de Laat
Leon Gommans
Univ. of Amsterdam Univ. of Amsterdam
Freek Dijkstra Freek Dijkstra
Univ. of Utrecht Univ. of Utrecht
Leon Gommans
Enterasys
Amol Kulkarni Amol Kulkarni
Ravi Sahita Ravi Sahita
Intel Intel
Kwok Chan Kwok Ho Chan
Nortel Networks Nortel Networks
Framework for Binding Access Control to COPS Provisioning Framework for Binding Access Control to COPS Provisioning
Last Updated: 7/13/01 Last Updated: 3/1/02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 51 skipping to change at page 2, line 5
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
Weiss et al. [Page 1]
Status of this Memo................................................1 Status of this Memo................................................1
Conventions used in this document..................................1 Conventions used in this document..................................1
Abstract...........................................................4 Abstract...........................................................4
1. Introduction....................................................4 1. Introduction....................................................4
2. Paradigm for the Bind PIB.......................................6 2. Paradigm for the Bind PIB.......................................6
2.1 Accessor Concepts..............................................6 2.1 Event Handler Concepts.........................................6
2.1.1 Example - Ethernet IP Address Authorization..................9 2.1.1 Example - Ethernet IP Address Authorization..................9
2.2 Accessor Management Paradigm..................................10 2.2. Context Data.................................................10
2.3. Context Data.................................................16 2.3. Policy Distribution and Management...........................11
2.4. Policy Distribution and Management...........................17 2.4. Interactions with DiffServ model.............................11
2.5. Interactions with DiffServ model.............................18 2.5. Interactions with RSVP model.................................12
2.6. Interactions with RSVP model.................................19 3. Supporting various client Authentication Protocols.............14
3. Supporting various client Authentication Protocols.............19 3.1. Provisioning.................................................14
3.1. EAP Authentication...........................................20 3.2. EAP Authentication...........................................15
3.1.1. EAP Message sequence.......................................20 3.2.1. EAP Message sequence.......................................15
3.1.2. AuthEapReXXExt data structures.............................22 3.2.2. AuthEapReqExt and AuthEapRespExt data structures...........17
3.2. PAP Authentication...........................................23 3.3. PAP Authentication...........................................17
3.2.1. PAP Connection sequence....................................23 3.3.1. PAP Connection sequence....................................18
3.2.2. AuthPapExtEntry datastructure..............................24 3.3.2. AuthPapExtEntry datastructure..............................19
3.3. CHAP Authentication..........................................24 3.4. CHAP Authentication..........................................20
3.3.1. CHAP Connection sequence...................................25 3.4.1. CHAP Connection sequence...................................20
3.3.2. AuthChapExtEntry datastructure.............................26 3.4.2. AuthChapExtEntry datastructure.............................22
3.4. HTTP Authentication..........................................26 3.5. HTTP Authentication..........................................23
4. Data Structures................................................27 4. Data Structures................................................24
4.1. Accessor class...............................................27 4.1. Event class..................................................24
4.2. AccessorElement class........................................28 4.2. EventHandler class...........................................24
4.3. AccessorSessionScope class...................................29 4.3. EventHdlrElement class.......................................25
4.4. AccessorAuthProtocol class...................................30 4.4. EventHdlrEventScope class....................................26
4.5. ContextData class............................................30 4.5. EventHdlrHandleScope class...................................28
4.6. Session class................................................31 4.6. Behavior of the Event and Handle Scope classes...............29
4.7. AuthExt class................................................32 4.7. EventHdlrAuthProtocol class..................................30
4.7.1. AuthEapReqExt class........................................33 4.8. DatapathEventHdlr Class......................................31
4.7.2. AuthEapRespExt class.......................................33 4.9. ContextData class............................................31
4.7.3. AuthPapExt class...........................................33 4.10. ContextData classes.........................................32
4.7.4. AuthChapExt class..........................................34 4.10.1. CtxtL3Hdr class...........................................32
4.8. ContextData classes..........................................34 4.10.2. Ctxt802Hdr class..........................................33
4.8.1. CtxtL3Hdr class............................................34 4.10.3. CtxtDialupInterface class.................................34
4.8.2. Ctxt802Hdr class...........................................36 4.10.4 CtxtDialupIfFramedProtocol class...........................35
4.8.3. CtxtDialupInterface class..................................36 4.10.5 CtxtDialupIfLoginService class.............................36
4.8.3.1 CtxtDialupIfFramedProtocol class..........................37 4.10.6 CtxtDialupIfLoginLat class.................................36
4.8.3.2 CtxtDialupIfLoginService class............................38 4.11. AuthExt class...............................................37
4.8.3.3 CtxtDialupIfLoginLat class................................39 4.11.1. UserAuthExt class.........................................37
4.11.2. AuthChapExt class.........................................37
4.11.3. AuthPapExt class..........................................38
4.11.4. AuthExtResult class.......................................38
4.11.5. AuthEapReqExt class.......................................38
4.11.6. AuthEapRespExt class......................................39
5. Message Types..................................................40 5. Message Types..................................................40
5.1. Accessor Provisioning Decisions..............................40 5.1. Event Handler Provisioning Decisions.........................40
5.2. Provisioning Report..........................................41 5.2. Provisioning Decision........................................41
5.3. PEP Access Request...........................................41 5.3. PEP Event Message............................................41
5.4. PDP Access Response..........................................41 5.4. PDP Provisioning Decision....................................42
5.5. Session-specific ContextData Request.........................42 5.5. PDP fetching Event-specific ContextData......................42
5.6. Session-specific ContextData Response........................43 5.6. Event-specific ContextData Response..........................43
5.7. Opaque Decision..............................................43 5.7. Opaque Decision..............................................43
5.8. Opaque Report................................................43 5.8. Opaque Report................................................43
6. Combining Data Structures in Messages..........................43 6. Combining Data Structures in Messages..........................45
6.1. Combining Context Data in Event Messages.....................45
Weiss et al. Expires October 2000 [Page 2] 7. Access Bind Usage Examples.....................................46
6.1. Combining Access Request and Session-specific ContextData 7.1 Wireless LAN (802.11 Access Point) Usage Example..............46
messages..........................................................44 7.1.1 Wireless LAN Access Event Handler Provisioning..............47
6.2. Combining Access Response and Provisioning Decision messages.44 7.1.2 Wireless LAN Access Event Handling..........................48
7. The AccessBind PIB Module......................................44 7.1.3 Wireless LAN Access Event Decision..........................48
8. Security Considerations........................................74 7.2 RSVP Usage Example............................................49
9. References.....................................................75 8. The AccessBind PIB Module......................................56
10. Author Information and Acknowledgments........................76 9. Security Considerations.......................................104
10. References...................................................105
Weiss et al. Expires October 2000 [Page 3] 11. Author Information and Acknowledgments.......................106
Abstract Abstract
There is an ever-growing distinction between edge and core There is an ever-growing distinction between edge and core
functionality. While the core continues to focus on stability and functionality. While the core continues to focus on stability and
pure forwarding functionality, the edges increasingly need to deal pure forwarding functionality, the edges increasingly need to deal
with dynamic capabilities like QoS management, VPN encapsulations, with dynamic capabilities like QoS management, VPN encapsulations,
encryption, dynamic steering and service monitoring. The dynamic encryption, dynamic steering and service monitoring. The dynamic
deployment of these functions is dependent on specific contextual deployment of these functions is dependent on specific contextual
knowledge such as the physical location of the data stream and the knowledge such as the physical location of the data stream and the
skipping to change at line 139 skipping to change at page 4, line 28
efficiently provision the appropriate set of policies for that efficiently provision the appropriate set of policies for that
client or account. It is possible to provide this capability with a client or account. It is possible to provide this capability with a
collection of currently available protocols. However, the collection of currently available protocols. However, the
synchronization of account and provisioning information between synchronization of account and provisioning information between
these protocols makes this approach extremely unwieldy. these protocols makes this approach extremely unwieldy.
This memo offers a solution in the form of a single COPS PIB capable This memo offers a solution in the form of a single COPS PIB capable
not only of supporting all the above requirements but also offering not only of supporting all the above requirements but also offering
a scalable means for extending the provisioning capabilities as new a scalable means for extending the provisioning capabilities as new
technologies are standardized. Specifically, we offer a mechanism technologies are standardized. Specifically, we offer a mechanism
for provisioning the criteria for initiating a dynamic authorization for provisioning the criteria for initiating dynamic event
requests from the PEP as well as a means for propagating credentials notifications from the PEP as well as a means for propagating
received by the PEP to allow the PDP to validate a client identity identity credentials received by the PEP to allow the PDP to
or an account. validate a client identity or an account as part of the event
notification process.
1. Introduction 1. Introduction
There are two sides to access control. The one side is the There are two sides to access control. The one side is the
negotiation between the client and the edge device (also known as negotiation between the client and the edge device (also known as
the policy enforcement point), for example between a workstation and the policy enforcement point), for example between a workstation and
an Ethernet switch supporting authentication protocols like 802.1x an Ethernet switch supporting authentication protocols like 802.1x
and PPPoE. The other side of a typical access control model is an and PPPoE. The other side of a typical access control model is an
interaction between the edge device (PEP) and a PDP, such that the interaction between the edge device (PEP) and a PDP, such that the
PDP performs the client/account validation process and notifies the PDP performs the client/account validation process and notifies the
skipping to change at line 166 skipping to change at page 5, line 5
is typically stored in a server (PDP). is typically stored in a server (PDP).
In reality access control can include authentication as one piece of In reality access control can include authentication as one piece of
a larger authorization process. As such, authorization has much in a larger authorization process. As such, authorization has much in
common with RSVP. When an RSVP service request is made, the PDP common with RSVP. When an RSVP service request is made, the PDP
evaluates a set of criteria including what is being requested, what evaluates a set of criteria including what is being requested, what
the availability of specific resources are, the identity of the the availability of specific resources are, the identity of the
requestor, and even the location of the requestor. All these requestor, and even the location of the requestor. All these
criteria are taken into consideration before determining whether the criteria are taken into consideration before determining whether the
RSVP request should be honored. In addition, if the request is RSVP request should be honored. In addition, if the request is
Weiss et al. Expires October 2000 [Page 4]
honored, specific provisioning actions may be taken to bound or honored, specific provisioning actions may be taken to bound or
manage the request. Similarly, the ability for a PDP to respond to a manage the request. Similarly, the ability for a PDP to respond to a
non-RSVP service request potentially requires all the same non-RSVP service request potentially requires all the same
information of a traditional RSVP request in order to determine information of a traditional RSVP request in order to determine
whether the request should be accepted or rejected. whether the request should be accepted or rejected.
It is also important to note that a service request should not just It is also important to note that a service request should not just
be restricted to network access. In practice, there are many be restricted to network access. In practice, there are many
instances where a determination of access privileges requires an instances where a determination of access privileges requires an
explicit decision. For instance, there are scenarios where limited explicit decision. For instance, there are scenarios where limited
network access is granted based on the specific criteria, but network access is granted based on the specific criteria, but
subsequent authorization is required to access a premium resource subsequent authorization is required to access a premium resource
that requires incremental authentication (via HTTP for example). that requires incremental authentication (via HTTP for example).
Another possible scenario occurs when initial access is authorized Another possible scenario occurs when initial access is authorized
based on one set of credentials, but usage of a specific resource based on one set of credentials, but usage of a specific resource
requires an examination of an account balance. These authorizations requires an examination of an account balance. These authorizations
will be referred to as ˘PEP Access Requests÷ to denote the fact that will be referred to as "PEP Events" to denote the fact that PEP is
PEP are requesting access to some type of service. generating an event indicating a request for some type of service.
In order to support the broad variety of potential PEP Access In order to support the broad variety of potential PEP Events, there
Requests, there must be a way of provisioning the criteria for must be a way of provisioning the criteria for generating the PEP
generating the PEP Access Request. In the most common case the PEP Event. In the most common case the PEP Event is generated as a
Access Request is generated as a result of some type of packet result of some type of packet oriented event such as activity on a
oriented event such as activity on a link, traffic of a particular link, traffic of a particular type or traffic from a new, unknown IP
type or traffic from a new, unknown IP address. address.
This leads to a useful observation: PEP Access Requests need to be This leads to a useful observation: PEP Events need to be defined
defined within the context of network data path. In other words, the within the context of a network data path. In other words, the data
data path mechanisms defined in the DiffServ informal model [MODEL] path mechanisms defined in the DiffServ informal model [MODEL] and
and the DiffServ PIB [DSPIB] provide a means for specifying the the DiffServ PIB [DSPIB] provide a means for specifying the
circumstances for generating a PEP Access Request by reusing circumstances for generating a PEP Event by reusing elements from
elements from the model like the qosDatapathTable table and the the model like the qosDatapathTable table and the qosClfrTable table
qosClfrTable table in the DiffServ PIB. in the DiffServ PIB.
Another consideration is the variety of information that can Another consideration is the variety of information that can
potentially be included in a PEP Access Request. For instance, a PEP potentially be included in a PEP Event. For instance, a PEP Event
Access Request could pass information about the client (domain), the could pass information about the client (domain), the physical port
physical port (dial up interface), L2 headers, L3 headers, (dial up interface), L2 headers, L3 headers, encapsulation headers
encapsulation headers (tunnels), cookies, and additional information (tunnels), cookies, and additional information already negotiated
already negotiated prior to generating the PEP Access Request. Given prior to generating the PEP Event. Given the amount of information
the amount of information that could be sent with the PEP Access that could be sent with the PEP Event, it is reasonable to allow the
Request, it is reasonable to allow the PDP to configure the PEP with PDP to configure the PEP with the set of information the PDP would
the set of information the PDP would like to have included with a like to have included with a specific type of PEP Event.
specific type of PEP Access Request.
PEP Access Requests provide a convenient means for the PEP to signal
an event that requires specific actions. A PDP authorization for
access to specific resources (and the potential verification of
identity) is one example of an event that not only requires a
response but also some potential provisioning work. It is
interesting to note how neatly RSVP decision support fits into this
model. In the original COPS design [COPS], the RESV request was sent
in a COPS request and a COPS response message determined whether the
Weiss et al. Expires October 2000 [Page 5] PEP Events provide a convenient means for the PEP to signal an event
reservation should be accepted or not. The enhancements provided by that requires specific actions. A PDP authorization for access to
this PIB not only allow RSVP messages to generate access requests, specific resources (and the potential verification of identity) is
but also explicitly provision QoS resources, using COPS-PR [COPSPR], one example of an event that not only requires a response but also
to support the reservation. This generalizes COPS for RSVP and some potential provisioning work. It is interesting to note how
allows it to evolve to the COPS-PR model. neatly RSVP decision support fits into this model. In the original
COPS design [COPS], the RESV request was sent in a COPS request and
a COPS response message determined whether the reservation should be
accepted or not. The enhancements provided by this PIB not only
allow RSVP messages to generate access requests, but also explicitly
provision QoS resources, using COPS-PR [COPSPR], to support the
reservation. This generalizes COPS for RSVP and allows it to evolve
to the COPS-PR model.
There are a number of situations where access requests need to be There are a number of situations where Events and associated
negotiated quickly. Mobile-IP applications in particular require provisioning need to be negotiated quickly. Mobile-IP applications
speedy resolution of PEP Access Requests. This implies that the in particular require speedy resolution of PEP Events. This implies
combination of PEP Access Requests and provisioning needs to be that the combination of PEP Events and provisioning needs to be
completed with the minimum number of communication legs (round completed with the minimum number of communication legs (round
trips). trips).
One of the problems discovered with existing PIBs [DSPIB, FPIB] was
that it was difficult to support two-phase classification. In the
general case, PEP Access Requests will be used to grant
authenticated clients access to specific resources. As such, many
clients are likely to share various combinations of resources.
However each resource is likely to be provisioned once and shared by
a set of clients. For example, a set of clients may share access to
a Virtual Private Network while a set of overlapping clients may
share access to a Voice over IP service, and a third set of
overlapping clients may be given access to a set of premium
services. The problem is that provisioning policies for each
combination of client and resource creates an n-square policy table
that is difficult to maintain and to scale. Provisioning the
resources independent of the consumer of the resources and binding
the two is a far more efficient approach allowing either resources
or clients to be managed independently of each other. However, this
requires approach requires two-phase classification, classifying the
client independent of the resource. This PIB will define incremental
structures to support this model.
2. Paradigm for the Bind PIB 2. Paradigm for the Bind PIB
There are several key aspects to this PIB. First there is the There are several key aspects to this PIB. First there is the
ability to provisioning for future authorization request, known as ability to provisioning for future authorization events, known as
PEP Access requests. Second, there is a set of tables that used to PEP Events. Second, there is a set of tables that used to notify the
notify the PDP of an attempt to access managed resources. These PDP of an attempt to access managed resources. These tables can also
tables can also include credentials necessary to verify client include credentials necessary to verify client identity. Finally,
identity. Finally, there are tables that provide a means for there are tables that determine how dialogs (COPS Request Handles)
dynamically binding sessions to a set of policies. This section between the PEP and PDP should be grouped. In order to provide
describes the approach taken for supporting each of these concurrency between competing events and provisioning requests,
structures. there must be a means for determining which PEP Events require a new
COPS Request Handle and which should use existing handles.
2.1 Accessor Concepts 2.1 Event Handler Concepts
This section introduces the concepts of an Accessor and Sessions This section introduces the concept of an Event Handler. Much of
associated with an Accessor. Much of what is described in this paper what is described in this paper is based on the Event Handler.
is based on the Accessors, the sessions that Accessors create, and
the way Accessors match data with sessions, creating new sessions
when there is no match.
Weiss et al. Expires October 2000 [Page 6] Event Handlers are implemented in PEPs and configured by PDPs. Event
Accessors are implemented in PEPs and configured by PDPs. Accessors Handlers are provisioned by standard COPS-PR protocol sequences. A
are provisioned by standard COPS-PR protocol sequences. A PEP will PEP will announce what Event Handlers are available in the
announce what Accessors are available in the capabilities table of capabilities table of the COPS-PR Request message. The PDP will
the COPS-PR Request message. The PDP will provision the Accessors provision the Event Handlers with Decision messages.
with Decision messages.
Once an Accessor is provisioned it is responsible for identifying Once an Event Handler is provisioned it is responsible for
packets that should be treated as a session, generating access identifying packets that require the PDP to be notified with an
requests to authorize the session when it detects the first packet Event Message.
of a session, and then applying a specific policy for all packets in
a session.
The general model for access requests includes a client, a Policy The general model for Event Messages requests includes a client, a
Enforcement Point (PEP) and a Policy Decision Point (PDP). In this Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). In
model, the PEP is the interface to the client, and the Accessor is this model, the PEP is the interface to the client, and the Event
the part of the PEP that is responsible for recognizing the Handler is the part of the PEP that is responsible for recognizing
conditions for client authorization, forwarding the Request to the the conditions for client authorization, generating the Event
PDP, and communicating with the Client, if necessary, to get Message to the PDP, and communicating with the Client, if necessary,
identity or other information. to get identity or other information.
The Accessor takes a signal or message from the client and The Event Handler takes a signal or message from the client and
translates it into an Access Request to send to the PDP. It takes translates it into an Event Message to send to the PDP. It takes the
the Access Decision from the PDP and, in cases where the client is provisioning Decision from the PDP and, in cases where the client is
aware of the authorization process, does what is needed to aware of the authorization process, does what is needed to
communicate the Decision to the client. communicate the Decision to the client.
The access request is sent from the PEP to the PDP. The PDP attempts The Event Message is sent from the PEP to the PDP. The PDP uses the
to authorize the request (which may require sending some Event Message to determine the appropriate provisioning steps. In
intermediate messages to authenticate the client), and then returns some cases identity verification may require sending some
an access Decision for the session. The PEP then returns a Report to intermediate messages to authenticate the client prior to
the PDP confirming what was provisioned by the Decision. provisioning the PEP with the policies appropriate to the client.
The PEP then returns a Report to the PDP confirming what was
provisioned by the Decision.
| C |->Access Request->| | | | | C |->Access Request->| | | |
| L | | |-Access Notification->| | | L | | |-Event Message---------->| |
| I | <-(optional)-> |PEP | <-(optional)-> |PDP | | I | <-(optional)-> |PEP | <-(optional)-> |PDP |
| E | | |<-Access Decision ----| | | E | | |<-Provisioning Decision -| |
| N |<-Access Decision-| | | | | N |<-Access Decision-| | | |
|__T_| |____| --> Access Report -->|____| | T | | | --> Access Report ----->| |
Fig. 2.1 Access Control Protocol Sequence Fig. 2.1 Access Control Protocol Sequence
This paper is primarily concerned with the function of the Accessor This paper is primarily concerned with the function of the Event
and the communication between the PEP and PDP. Communication between Handler and the communication between the PEP and PDP. Communication
the Client and PEP is assumed to be something like PPP or 802.1, and between the Client and PEP is assumed to be something like PPP or
the capabilities described here should work with any Client/PEP 802.1, and the capabilities described here should work with any
communication method. Client/PEP communication method.
The PEP Access Request and PDP Access Response sequence is similar
to the ˘classical÷ COPS RSVP model. The Report confirming that the
Decision was installed correctly on the PEP is an extra message
Weiss et al. Expires October 2000 [Page 7] The PEP Event Message and PDP Provisioning Decision sequence is
beyond what is included in the RSVP sequence. We believe this is a similar to the "classical" COPS RSVP model. The Report confirming
good approach, but expect further discussion (It is interesting to that the Decision was installed correctly on the PEP is an extra
note that RADIUS does not send an acknowledgements of Access message beyond what is included in the RSVP sequence. We believe
Accepts/Rejects, and the DIAMETER drafts specify no acknowledgement, this is a good approach, but expect further discussion (It is
but do expect a negative message if the Reply cannot be processed interesting to note that RADIUS does not send an acknowledgements of
correctly). Access Accepts/Rejects, and the DIAMETER drafts specify no
acknowledgement, but do expect a negative message if the Reply
cannot be processed correctly).
An Accessor is a data path element in the PEP. Each Accessor has a An Event Handler is a data path element in the PEP. Each Event
˘selector÷ that identifies packets that should be assigned by the Handler has a "selector" that identifies packets that should cause
accessor to a session (See section 4.3 ű Filter Entries). The Event Messages (See section 4.3 - Filter Entries). The selector
selector essentially divides all packets into two sets, one set the essentially divides all packets into two sets, one set the Event
Accessor is responsible for assigning to a session; the other set it Handler is responsible for generating Event Messages; the other set
just passes to the next data path element. For example, if an it just passes to the next data path element. For example, if an
AccessorĂs selector is Destination TCP Port = 80, an incoming Event HandlerĂs selector is "All new source IP addresses", an
packetĂs Destination port is examined and if Destination Port is not incoming packetĂs Source IP address is examined and if it is old,
80, the packet passed on without further processing. If the the packet passed on without further processing. If the source IP
Destination Port is 80, each packet is associated with a ˘session÷ address is new or unknown, an Event Message is generated.
and the session policy is applied to it. If a packet is the first of
a session, the Accessor will initiate an Access Request to authorize
and request provisioning for the new session.
Every session has a ˘session criteria÷ defining which packets are to Event Messages are grouped by COPS Request Handles. Each Event
be part of that session. (note: see section 4.3. The distinction Message may cause a new COPS Request Handle to be generated or a set
between selector and session criteria is not well spelled out in of Event Messages may all share the same COPS Request Handle (note:
4.3, and will be worked on in the next revision of this draft). Each see section 4.3-4.6). The distinction between selector and Event
Accessor also has a ˘session matcher÷ that checks session criteria Handle spelled out in 4.3-4.6, and will be worked on in the next
to determine if a packet is part of an existing session. revision of this draft). Attributes in the Access Bind PIB are
provided to identify what how Event Messages are bound to COPS
Request Handles.
There has been some discussion of what the session criteria should Event Handlers are designed to detect conditions in the PEP that
be. One possibility is that there would be a definition of scope by result in the sending of Event Messages to the PDP. The Access Bind
a set of attributes (e.g. every Source IP and Destination IP address PIB defines a class to specify the criteria for generating an event.
combination) and that every unique element that is in the scope In some cases an event is appropriate every time the criteria is
would be a session. The approach taken in this paper is that the met. In other instances an event is appropriate only on the first
scope is defined by Filter entries defined in the COPS Framework PIB occurrence. The provisioning event criteria can be difficult since
[FWPIB]. For example, if a FilterEntry object specifies SRC IP it is often the case that the PDP canĂt anticipate what the PEP will
address (10.20.0.0) and SRC IP Mask (FF.FF.0.0) each new IP address see. For instance, when it is desirable to generate events every
within the range 10.20.0.0 and 10.20.255.255 will trigger a new time a new user or device is recognized, the PDP canĂt anticipate
session. The session criterion is that all packets that have a which devices will be recognized or the order in which they will
unique value within the scope are assigned to the (unique) session occur. Filter expressions can be constructed that enable the
associated with that unique value. (We expect discussion on how the description of a set of packet fields that must match and a set of
scope is defined, especially for situations that involve signaling packet fields that collectively represent a new, unique combination.
rather than inspecting packet headers) This expressive capability allows the PDP to indicate to the PEP
that one event should be generated the first time a Src IP address
has been seen by the PEP, but not generate events for subsequent
packets with the same Src IP address.
When a packet arrives, the Accessor first checks if it meets the One interesting problem associated with event driven provisioning is
general criteria for sessions it is managing. In the example above, avoiding blocking of one event due to provisioning activity for a
a packet with a SRC IP address of 10.25.12.100 would not match the different event. On the other hand, there are situations where
range criteria. If not selected, it is passed to the next data path serialization or ordering of events is important. We use COPS
element. If it is selected, then a check is made to see if it Request Handles to address both these needs. However, this requires
matches the criteria for an existing session. If it does match a explicit provisioning to indicate when new handles should be
session criteria, the policy for that session is applied. provisioned and which events should be processed through which
handles. The approach taken in this paper is that the scope of the
COPS Request Handle is defined by one or more Filter entries defined
in the COPS Framework PIB [FWPIB], this PIB and other PIBs. For
example, if a FilterEntry object specifies SRC IP address
(10.20.0.0) and SRC IP Mask (FF.FF.0.0) each new IP address within
the range 10.20.0.0 and 10.20.255.255 will trigger the creation of a
new Handle. The for this example, any packet with a SRC IP address
that generates a new Event Message will use the existing handle if
that handle was already defined for that specific SRC IP address.
If it does not match the criteria for an existing session, then it When a packet arrives at the Event Handler, it first checks if it
instantiates a new session, marks the session as ˘pending÷ and sends meets the criteria for generating an Event (event criteria will be
discussed later). In the example above, a packet with a SRC IP
address of 10.25.12.100 would not match the range criteria and would
be passed to the next data path element. If it is selected, then a
check is made to see if it matches the criteria for an existing COPS
Request Handle.
Weiss et al. Expires October 2000 [Page 8] If it does not match the criteria for an existing COPS Request
an Access Request to the PDP. The PDP authorizes the request, Handle, then the PEP instantiates a new Request Handle and sends an
possibly sending additional messages to support authentication and Event Message to the PDP using the new Handle. In either case the
provisioning for the session, then sends an Access Decision ű either PDP analyzes the Event Message, possibly sending additional messages
an ˘Enable÷ (accept) or ˘Disable÷ (reject) ű to the PEP. The Access back to the PEP to support authentication and provisioning for the
Decision may also contain other provisioning data piggybacked with new address. If authentication was performed, a final Authentication
the Access Decision. Result object is sent to the PEP to indicate the authentication was
successful or not. This is needed to allow the PAP, CHAP and EAP
authentication processes to report success back to the
authenticating user.
2.1.1 Example - Ethernet IP Address Authorization 2.1.1 Example - Ethernet IP Address Authorization
This (relatively simple) example assumes an edge device has an This (relatively simple) example assumes an edge device has an
Ethernet interface and wants to require each new Source IP address Ethernet interface and wants to require each new Source IP address
arriving at one Ethernet port to be authorized before getting general arriving at one Ethernet port to be authorized before getting general
access to the network. Assume also that some clients are to get access to the network. Assume also that some clients are to get
preferred access (via DiffServ Marking). preferred access (via DiffServ Marking).
In the example, the PEP is configured with two policies used by In the example, the PEP is configured with a classifier that has
Accessor sessions to direct traffic from two sets of authorized IP explicit entries for each source address that has already be
addresses to an appropriate data path, one to the preferred queue, authenticated and a default classifier element matching all addresses
the other to the best effort queue. Packets from IP addresses not to points to an Event Handler. Since the default classifier element
included in either set of authorized IP addresses are to be dropped. is only used if none of the other classifier elements match, the
Event Handler is only invoked for new Src IP addresses that have not
When the PEP comes up it sends information about its Accessors to the yet been explicitly provisioned into the classifier. Each non-default
PDP in a capabilities table. The PDP returns an Accessor Provisioning classifier element points to another classifier that lists the
Decision which instructs the PEP to install the Accessor behind the policies uniquely for that Src IP address. The addresses of "premium"
Ethernet interfaceĂs datapath, and AccessorSessionScope Tables. Each users are assigned a high QoS while the addresses of "normal" users
Accessor Table will have a pointer to a (tagged) set of are assigned best effort QoS. Since the Event Handler is not
AccessorSessionScope Tables that provide Selector and Session terminating any packets, the Event Handler passes all packets through
Matching setup information. In this case, the AccessorSessionScope to the Best Effort Queue.
table will contain a range of ˘SourceIPAddresses.÷
Once the Accessor is setup, packets arriving at the Ethernet
Interface are processed by the Accessor. If the packet is not from
EthernetPort 1, then it is passed immediately to the next data path
element behind the Accessor.
The Accessor looks at remaining packets and uses the session matching
rules to check if the packet is part of an existing session. In this
example packets from each unique Source IP address will be separate
sessions. If the packet is not part of an existing session, the
Accessor checks what information the PDP requires from the Client
(e.g. username and credential), gets the information, instantiates a
new (pending) session with this Source IP address, and sends an
Access Request to the PDP.
The PDP checks the packet, authenticates the client (if required),
and decides which policy should apply to that IP address. It sends a
Access Decision to the PEP including the Session Table with state
set to ˘Enabled÷ and a pointer to appropriate policy (e.g. best
effort or preferred).
Weiss et al. Expires October 2000 [Page 9]
Future drafts will expand on this example and add other examples.
Current plan is to add examples for dial access and QoS flow
authorization.
2.2 Accessor Management Paradigm
Figures 2.2 through 2.6 below show a number of diagrams representing
a sequence of steps involved in the authorization, authentication
and provisioning phase. The semantics of this are shown as layout of
switches and Connections. Switches, Accessor and Policy components
in a topology that describe certain traffic classifications
represent access to Service capabilities enforced by the PEP.
The following diagrams represent the semantic components within the
PEP. Each (A) represents an Accessor. An Accessor is a logical
component inside the PEP that can be created and/or configured
during the PEP initialization phase or it gets instantiated as the
result of an unsolicited Provision Decision from the PDP.
An Accessor is configured to act on certain messages or interface
events (as described in section 2.1). After matching a packet and
determining that no session exists for it, the Accessor in the PEP
will create a new session and assert the start of an authorization
phase by sending an Access Request to the PDP (or AAA server). This
authorization phase may include authentication as well.
The configuration of an Accessor will include a list of the types of
authentication methods (PAP/CHAP/ EAP/HTTP etc.) to be used. Each
(S) within the topology represents an active unique session created
by the PEP, replacing the Accessor symbol when the session is
activated (as will be explained later). A single Accessor component
is capable of creating multiple Session instances that each
represent a unique session as represented in the subsequent example.
The (P) symbols represent provisioned policies. Policies are created
and/or made accessible or inaccessible in the PEP based on
Provisioning Decisions from the PDP. Provisioning Decisions can be
sent on request by the PEP or can be sent unsolicited by the PDP.
Switches: closed or ON: --o---o--.
\
open or OFF : --o \o--
In this example there are two kinds of switches:
- Accessor Switches: --(An)---o--
A logical switch that is connected to the Accessor and can be seen
as a kind of master switch that enables a group of Services at once.
Under normal circumstances the switch remains open until an explicit
access response is sent by the PDP. This allows the PDP to perform
preemptive provisioning prior to providing closing the switch.
Weiss et al. Expires October 2000 [Page 10]
- A Policy Switch: --o---o--(Pn) Service/Resource
(Pn) is a logical switch that represents a policy. The (Pn) open
switch defines a policy that denies resources and a closed switch
describes policies that enable services. The figures simplify
policies to permit and deny. In practice a policy provisioned by the
PDP can express QoS semantics, tunnel semantics, or even high level
services such as telephony services. In figures 2.2 through 2.6,
these services are represented as branches.
The Accessor Switch can be explicitly operated by a response to the
PEP Access Request. This response will hereafter be referred to as a
˘PDP access response÷ message.
DISABLE
Link \
----(A1) \o-- Access Request
Activity
Fig 2.2: The PEP waits for traffic that initiates a PEP Access
Request.
Figure 2.2 shows the PEP Accessor A1 is waiting to receive an event
that will initiate a PEP Access Request to the PDP. This Accessor
(A1) can be configured by the PDP either at boot time or it could
exist permanently in the non-volatile memory of the PEP after a one-
time configuration of the PEP. For the purposes of this example, we
will assume that Accessor (A1) has been instantiated a new Session
due to link activity and a PEP Access Request message has been sent
to the PDP.
HTTP ENABLE
|----------o---o---(P1) tunnel to content filter
|
| DISABLE
|Non IP \
|----------o \o---(P2) drop
|
DISABLE |10.x.x.x ENABLE
\ |----------o---o---(P3) tunnel corporate traffic
----(S1) \o--|
|24.x.x.x \
|-------(A2) \o--- Access Request
|
|All other
|traffic ENABLE
|----------o---o---(P4) default QoS
Fig 2.3: The PDP provisions policies P1, P2, P3 & P4 and Accessor
A2.
Weiss et al. Expires October 2000 [Page 11]
The PEP Access Request generated by (A1) can be configured such that
it sends specific information about the client including physical
link characteristics, L2, L3 & tunnel information, as well as
authentication credentials. For some authentication protocols there
may be sufficient information to allow the PDP to authorize the
access request. If additional information is required, a number of
data structures are defined in the PIB to allow additional
negotiation for either the authentication or the authorization to be
completed. These structures are discussed in more detail in the next
section.
When the PDP is ready to grant access, it can choose to provision
specific services for the session bound to the access request. These
service policies can be dynamically bound to the session via the
NextElement attribute in the Session table (discussed in detail in
section 4.5). This attribute allows sessions, generated by PEP
Access Requests, to be bound to other data path elements describing
the necessary configuration to support additional service policies.
The example in Figure 2.3 replaces the Accessor (A1) with Session
(S1) to demonstrate that the policy bindings are at the session
level rather than at the Accessor level. For simplicityĂs sake the
Accessor is not shown in the figure. In this example the Session is
followed by a classifier, and a set of QoS and tunneling services
are defined to provide access to services defined with policies P1,
P3 & P4, as well as explicit deny policy P2. The diagram shows that
services such as tunnels for certain traffic types (P1/P3) and a
default QoS treatment (P4) is enabled and that access of Non-IP
traffic to the network is denied (P2). The PDP also provisions a new
Accessor (A2) that will trigger the generation of a new PEP Access
Request if/when traffic is destined for IP subnet 24.x.x.x.
This ability to support multiple Accessors as well as a hierarchy of
Accessors is a key capability of this model. There are many
scenarios where multiple authorizations are required for the same
client. Further any of these authorizations can require incremental
authentication.
Weiss et al. Expires October 2000 [Page 12]
HTTP ENABLE
|----------o---o---(P1) tunnel to content filter
|
| DISABLE
|Non IP \
|----------o \o---(P2) drop
|
|10.x.x.x ENABLE
ENABLE |----------o---o---(P3) tunnel corporate traffic
----(S1)--o--|
| DISABLE
|24.x.x.x \
|-------(A2) \o-- Access Request
|
|All other
|traffic ENABLE
|----------o---o---(P4) default QoS
Fig 2.4: The PDP enables services by sending a PDP Access Response.
Figure 2.4 above shows the state of the data path after the
authorization has been completed. After any incremental data path
provisioning performed by the PDP, the PDP sends an explicit
response to the PEP Access Request. This response, referred to as
the ˘PDP Access Response,÷ notifies the PEP that traffic is now
allowed to pass through the session (S1) created with Accessor (A1).
Once the Session is enabled, traffic can now proceed to the
classifier that will forward traffic on to the specified policies
(P1, P3 & P4) or cause a new PEP Access Request for (A2).
Weiss et al. Expires October 2000 [Page 13]
HTTP ENABLE
|----------o---o---(P1) tunnel to content filter
|
| DISABLE
|Non IP \
|----------o \o---(P2) drop
|
|10.x.x.x ENABLE
ENABLE |----------o---o---(P3) tunnel corporate traffic
----(S1)--o--|
| 24.20.x.x ENABLE
| |----------o---o---(P5) high QoS
| DISABLE |
|24.x.x.x \ |24.1.x.x ENABLE
|-------(S2) \o--|----------o---o---(P6) low QoS
| |
| | DISABLE
| |TELNET \
| |----------o \o---(P7) drop
|All other
|traffic ENABLE
|----------o---o---(P4) default QoS
Fig 2.5: Accessor 2 triggers new PEP Access Request resulting in PDP
Provision Decisions installing policies P5, P6, & P7.
In figure 2.5, above, the second Accessor (A2) (shown as S2) has
been triggered with a packet from the client to subnet 24.x.x.x
resulting in a PEP Access Request and the creation of a new Session
(S1) by the PEP. Figure 4 also demonstrates the PDPĂs ability to
incrementally apply additional provisioning decisions. In the
example, additional classification and provisioning components are
provisioned behind the new session (S2) to apply more selective QoS
to specific types of traffic via policies P5 and P6.
Weiss et al. Expires October 2000 [Page 14]
HTTP ENABLE
|----------o---o---(P1) tunnel to content filter
|
| DISABLE
|Non IP \
|----------o \o---(P2) drop
|
|10.x.x.x ENABLE
ENABLE |----------o---o---(P3) tunnel corporate traffic
----(S1)--o--|
| 10.20.x.x ENABLE
| |----------o---o---(P5) high QoS
| |
| ENABLE |10.1.x.x ENABLE
|-------(S2)--o--|----------o---o---(P6) low QoS
| |
| | DISABLE
| |TELNET \
| |----------o \o---(P7) drop
|All other
|traffic ENABLE
|----------o---o---(P4) default QoS
Fig 2.6: The PEP receives PDP Access Response and enables S2.
In figure 2.6, after all Provision Decisions have been reported
successfully, the PDP will send a PDP Access Response that will
enable access to all the services behind Session S2.
Services and Accessors are provisioned and given a certain state
either as a default during the first contact phase with the PDP or
during the operational period as updates from the PDP driven by PEP
Access Requests. Typically the default configurations are requested
by the PEP at startup time and the PDP returns Provision Decisions
based on the context data described in the Request.
Provision Decisions may arrive at the PEP solicited (after the PEP
sends a Provision Request) or unsolicited. Provision Decisions that
are sent unsolicited to the PEP may create additional switches
(services), enable or disable switches or it may remove a Service
Switch or even an Accessor Switch. In addition, it is also possible
for an existing, enabled Accessor Switch to be disabled dynamically.
Provision Reports subsequently sent from the PEP to the PDP will
confirm that a particular switch is created, has a certain status or
is removed.
A Provision Report does not always imply that the endpoint of a
particular service is operational since PEP only controls the access
to a particular service.
After a particular client has been identified to the PDP, the PDP
will decide which Services will be provisioned to this particular
Weiss et al. Expires October 2000 [Page 15]
client. There may be a set of Provision Decisions that must be
˘Reported÷ as successfully installed to the PDP before the PDP sends
a PDP Access Response to control all (or a set of) services. For
example a certain set of security settings must be in place before
the PEP is allowed to have the client send any packet to the network
behind the PEP.
A solicited or unsolicited Provision Decision may also create new When the PEP comes up it sends information about its Event Handlers
Accessors as illustrated in Figures 2.2 through 2.6. Provisioning to the PDP in a capabilities table. After capability negotiation is
additional Accessors may be seen as an extension to the original complete, the PDP provisions a set of policies that configure the
access and provision sequence or may be seen as an independent Event Handlers behind the Ethernet interfaceĂs datapath. Each Event
event. Handler Table will have a pointer to a (tagged) set of
EventHandlerElement Tables that provide Filter matching and COPS
Request Handle matching rules. In this case, the EventHandlerElement
table will be provisioned generate unique Request Handles and Events
the first time it matches a new "SourceIPAddresses."
A use case for multiple Accessors might be that the first Accessor Once the Event Handler is setup, it is able to process packets
causes a default service to be provisioned that only requires very arriving at the Ethernet Interface. The Event Handler looks at all
basic authorization (e.g. based on source IP address) and that more packets with Src IP addresses that have not been explicitly been
elaborate authentication is only required when the client accesses defined in the upstream Classifier and uses the event matching rules
web servers in a certain IP address range. For this reason, the to check if the packet contains an unknown Src IP address within the
second Accessor may be configured to trigger on any HTTP packet to a configured range. If the packet matches an event matching rule, the
certain range of IP addresses or it could be configured to trigger Event Handler checks what information the PDP requires from the
on a specific HTTP GET request. The PDP may subsequently create a Client (e.g. username and credential), and collects this
service switch to a specific IP address for port 80 marking the information. The PEP then checks to see if it should use an existing
traffic for a High QoS. Request Handle or create a new one. In this example, each new
address gets a unique COPS Request Handle so that all the address-
specific (user specific) policies (and feedback information) are
managed through a single COPS dialog. A unique handle also has the
benefit of automatically removing all objects provisioned through
the Handle when the Handle is deleted (the user ends their session).
After the Request Handle is set up, an Event Message is sent to the
PDP containing the user information including address, port, and
credential information.
Additional Accessors may trigger PEP/PDP Access Request/Response The PDP checks the information passed in the Event Message,
sequences on behalf of different parties. This is part of the authenticates the client (if required), and decides which policy
Accessor configuration provided by the PDP. The PDP may create should apply to that IP address. It sends a Provisioning Decision,
Accessors without explicit knowledge of the client. containing the appropriate policy (assign to "premium" queue) to the
PEP using the newly created Request Handle.
As stated previously, in order for the PEP to generate a PEP Access Additional examples using the Access Bind PIB to support RSVP,
Request, the PEP must be configured not only to generate the request 802.11, and other protocols are described in section 7.
under the proper circumstances, but also what physical interface and
transport header information should be passed with the request. This
configuration must also include the authentication rules that may be
supported. The semantics of the PEP Access Request are discussed in
detail in sections 5.1 and 6.1.
2.3. Context Data 2.2. Context Data
As mentioned previously, access requests frequently require As mentioned previously, Event Messages frequently require
information beyond just the identity of the client. Information information beyond just the identity of the client. Information
about the physical interface, the protocols being used, and the about the physical interface, the protocols being used, and the
protocol bindings (VLANs, IP addresses, etc.) may also be required protocol bindings (VLANs, IP addresses, etc.) may also be required
to complete an access request. Therefore a mechanism is required to provide enough information to the PDP to provide proper
that allows the PDP to specify what information is needed. provisioning guidance. Therefore a mechanism is required that allows
the PDP to specify what information is needed.
With the advent of Tunnels, the same headers can be repeated With the advent of Tunnels, the same headers can be repeated
(nested) within a single client message. This makes identification (nested) within a single client message. This makes identification
of specific attributes such as IP Addresses difficult because it is of specific attributes such as IP Addresses difficult because it is
unclear whether the PDP needs the IP Address in the innermost or unclear whether the PDP needs the IP Address in the innermost or
outermost header. This gets even more complicated when more than two outermost header. This gets even more complicated when more than two
layers are involved (i.e. VLAN and label stacking). The ContextData layers are involved (i.e. VLAN and label stacking). The ContextData
class, described in more detail below, allows the PDP to explicitly class, described in more detail below, allows the PDP to explicitly
Weiss et al. Expires October 2000 [Page 16]
specify the set of nested headers that it needs more details on. specify the set of nested headers that it needs more details on.
This can either be specified in from the outermost header or the This can either be specified in from the outermost header or the
innermost header, as well as all headers of a particular type. innermost header, as well as all headers of a particular type.
Since the volume of information can be quite large and is very PEP Since the volume of information can be quite large and is very PEP
and interface specific, it is appropriate to organize the and interface specific, it is appropriate to organize the
information into manageable chunks. This approach was a compromise information into manageable chunks. This approach was a compromise
between two extremes. One extreme is one large data structure with between two extremes. One extreme is one large data structure with
all possible information. The other extreme is specifying each all possible information. The other extreme is specifying each
attribute explicitly. The first extreme is not viable because it is attribute explicitly. The first extreme is not viable because it is
skipping to change at line 777 skipping to change at page 11, line 4
data that must distinguish inner and outer headers. The choice to data that must distinguish inner and outer headers. The choice to
group context data into classes and request the data at the class group context data into classes and request the data at the class
level is not without problems. If the PDP is only interested in a level is not without problems. If the PDP is only interested in a
single attribute within a given class, there is no way to specify single attribute within a given class, there is no way to specify
this. Hence the PEP has to fill in the entire class and the PDP has this. Hence the PEP has to fill in the entire class and the PDP has
to parse the entire class to find the appropriate attribute. to parse the entire class to find the appropriate attribute.
In order for the PDP to specify which chunks of context data it In order for the PDP to specify which chunks of context data it
needs, this PIB defines a table called the ContextData class that needs, this PIB defines a table called the ContextData class that
allows the PDP to specify the tables it needs. This table is allows the PDP to specify the tables it needs. This table is
discussed in more detail in section 4.4. The messages used to send discussed in more detail in section 4.9. The messages used to send
ContextData are discussed in sections 5.1, 5.2, and 5.3. ContextData are discussed in sections 5.1, 5.2, 5.3, and 6.1.
2.4. Policy Distribution and Management 2.3. Policy Distribution and Management
One of the purposes of this memo is to demonstrate how authorization One of the purposes of this paper is to demonstrate how
and authentication can be bound to traditional COPS provisioning. authorization and authentication can be bound to traditional COPS
Stated somewhat differently, this memo provides the means for provisioning. Stated somewhat differently, this paper provides the
seamlessly integrating outsourcing with provisioning using only means for seamlessly integrating outsourcing with provisioning using
PIBs. Authorization, Authentication, and COPS/RSVP are all forms of only PIBs. Authorization, Authentication, and COPS/RSVP are all
outsourcing because they are all triggered by events in the PEP and forms of outsourcing because they are all triggered by events in the
depend on decision support from the PDP. Earlier sections have gone PEP and depend on decision support from the PDP. Earlier sections
into a fair bit of detail in describing how the PEP can generate have gone into fair detail in describing how the PEP can generate
access requests. However, we have not yet discussed how these Event Messages. However, we have not yet discussed how these
semantics integrate with traditional COPS PR provisioning semantics. semantics integrate with traditional COPS PR provisioning semantics.
There are two aspects to provisioning that need to be considered. There are two aspects to provisioning that need to be considered.
First is the provisioning of the Accessors themselves. Section 2.1 First is the provisioning of the Event Handlers themselves. Section
went into some detail describing how Accessors are provisioned using 2.1 went into some detail describing how Event Handlers are
policy decisions. More details on the Accessor tables can be found provisioned using policy decisions. More details on the Event
in sections 4.1, 4.2, and 4.3. In addition the provisioning messages Handler tables can be found in sections 4.1, 4.2, and 4.3. In
used to configure Accessors are also described in section 5.1. addition the provisioning messages used to configure Event Handlers
are also described in section 5.1.
The second aspect of provisioning is the use standard provisioning The second aspect of provisioning is the use standard provisioning
decisions to bind policies to authorized clients. The goal in decisions to bind policies to authorized clients. The goal in
binding sessions to policies was to minimize reconfiguration. binding events to policies was to minimize reconfiguration.
Therefore, this PIB has been designed to configure Accessors as well Therefore, this PIB has been designed to provision Event Handlers as
as Policies once and bind them together dynamically. well as Policies once and bind them together dynamically.
The process for this binding is as follows. An Accessor can be
configured to generate sessions and trigger a PEP Access Requests
Weiss et al. Expires October 2000 [Page 17] The process for this binding is as follows. An Event Handler can be
based on specific criteria. These criteria explicitly scope the configured to generate COPS Request Handles and trigger an Event
session. For example, if the criteria were one per unique source IP Message based on specific criteria. These criteria explicitly scope
address, then there would be one session for each unique source IP the Request Handle. For example, if the criteria were one per unique
address and all policies bound to that session would operate on all source IP address, then there would be one Request Handle for each
traffic with that source IP address flowing into that Accessor. Note unique source IP address and all policies bound to through that
that the criteria that scope a session could also be a unique Request Handle would typically operate on all traffic with that
protocol, unique VLAN, or each unique RSVP RESV message. It is also source IP address. Note that the criteria that scope a Request
worth noting that the session bounding criteria could also be a Handle could also be a unique protocol, unique VLAN, or each unique
unique combination of field values such as a VLAN and TCP Port RSVP RESV message. It is also worth noting that the Request Handle
Number. bounding criteria could also be a unique combination of field values
such as a VLAN and TCP Port Number.
With the scope of a session specified, the Accessor can instantiate With the scope of a Handle specified, the Event Handler can
new sessions in conjunction with the PEP Access Request. When the instantiate new Handles in conjunction with the Event Message.
PDP authorizes a new session, it must bind specific policies to the
session in order to specify how the session-specific traffic should
be processed. If no specialized handling is required for the
individual sessions, the sessions may all be lumped back into a
single data path. Normally the next data path element will be a
classifier that de-multiplexes specific or aggregate session traffic
to the various service policies configured behind the classifier. As
such an Accessor performs a sort of classification function that
instantiates additional more specific policies, provisioned in the
PEP. This can be viewed as a boot strapping process for handling
session specific access control.
2.5. Interactions with DiffServ model 2.4. Interactions with DiffServ model
The DiffServ model [MODEL] and PIB [DSPIB] allow for flexible The DiffServ model [MODEL] and PIB [DSPIB] allow for flexible
addition of new Data Path Functional Elements. Accessor is one such addition of new Data Path Functional Elements. The Event Handler is
new Data Path Functional Element. Previous sections have already one such new Data Path Functional Element. Previous sections have
described how this PIB extends the existing DiffServ Informal Model already described how this PIB extends the existing DiffServ
and the DiffServ PIB. However, it is worth describing how this PIB Informal Model and the DiffServ PIB. However, it is worth describing
enhances the basic DiffServ model. First and foremost, this new PIB how this PIB enhances the basic DiffServ model. First and foremost,
provides a means for scaling the basic DiffServ model to the edges this new PIB provides a means for scaling the basic DiffServ model
of the network that can have many interfaces and many specialized to the edges of the network that can have many interfaces and many
services. Previous PIBs only supported the static configuration of specialized services. Previous PIBs only supported the static
data paths. This meant that dynamic events such as binding of new configuration of data paths. This meant that dynamic events such as
clients to existing or new services were difficult to support binding of new clients to existing or new services were difficult to
because there was no way to anticipate new clients and because most support because there was no way to anticipate new clients and
provisioning was managing classifiers on a per client per service because most provisioning was managing classifiers on a per client
basis did not scale well. per service basis did not scale well.
This PIB addresses this problem by preserving the basic data path This PIB addresses this problem by preserving the basic data path
semantics but separating the creation of sessions into a new data semantics but separating the creation of dynamic (event driven)
path component. This provides a stable data path for the generation policies into a new data path component. This provides a stable data
of sessions (and authorizations) while also supporting a stable data path for the generation of authorizations while also supporting a
path for the services that various sessions may make use of. The stable data path for the services that various clients may make use
linchpin of this PIB is the Accessor that provides a new form of a of. The linchpin of this PIB is the Event Handler that provides a
demultiplexor that separates streams of traffic into individually new type of demultiplexor that separates streams of traffic into
authorizable sessions. These sessions can in turn be bound to pre- individually grouped triggers that in turn support dynamic
configured services. Further, with this PIB, modifications to authorization. The policy provisioning that results from these
service policies can added or removed at the session level rather events can be bound back to pre-defined policies to minimize the
than the raw data path level. changes required to support new clients. As a result, with this PIB,
modifications to service policies can be added or removed at the
session level rather than the raw data path level.
Weiss et al. Expires October 2000 [Page 18] So far we have only discussed the value of authorizing a client when
So far we have only discussed the value of authorizing a session the link notices new IP address. However, it is worth noting that
when the link notices new IP address. However, it is worth noting because the Event Handler is part of the data path definition, it is
that because the Accessor is part of the data path definition, it is far more flexible. For instance, the Event Handler can be placed
far more flexible. For instance, the Accessor can be placed behind a behind a Classifier to explicitly authorize access to a specific
Classifier to explicitly authorize access to a specific part of the part of the network or specific services. The Event Handler can also
network or specific services. The Accessor can also be the FailNext be the FailNext element behind a meter resulting in an authorization
element behind a meter resulting in an authorization for the use of for the use of out-of-profile traffic. Bandwidth Brokers can use
out-of-profile traffic. Bandwidth Brokers could use this approach or this approach or an Event Handler trapping RSVP RESV messages to
an Accessor trapping RSVP RESV messages to support dynamic bandwidth support dynamic bandwidth allocation decisions.
allocation decisions.
The integration of Accessor and Session as Data Path Functional The integration of Event Handler as a Data Path Functional Element
Elements allows seamless integration with DiffServ provisioning. allows seamless integration with DiffServ provisioning.
DiffServ network device mechanism policy control continues to be DiffServ network device mechanism policy control continues to be
supported with the use of DiffServ PIB [DSPIB] with added supported with the use of DiffServ PIB [DSPIB] with added
functionality at the edge of the network with usage of Accessor and functionality at the edge of the network with usage of the Event
Session. Totally controlled via the use of COPS-PR. Handler. This can now be totally controlled via the use of COPS-PR.
The Policy Server level interaction with DiffServ comes naturally The Policy Server level interaction with DiffServ comes naturally
with the integration of Accessor and Session as Data Path Functional with the integration of Event Handler as a Data Path Functional
Elements when the network data model is common and scoped Element when the network data model is common and scoped
appropriately in the schema level, with the Accessor becoming appropriately in the schema level, with the Event Handler becoming
stimuli for DiffServ provisioning. stimuli for DiffServ provisioning.
2.6. Interactions with RSVP model 2.5. Interactions with RSVP model
The Accessor model provides a means for detecting RSVP RESV The Event Handler model provides a means for detecting RSVP RESV
messages. This means that the traditional COPS outsourcing model messages. This means that the traditional COPS outsourcing model
could eventually be phased out in favor of the provisioning model could eventually be phased out in favor of the provisioning model
and the use of this PIB. Before this option is fully realized one and the use of this PIB. This is discussed in more detail in section
issue will need to be addressed. Because RSVP uses the same message 7.2.
to create a reservation as it does to modify the reservation, new
hooks will need to be supplied in the Accessor in order to detect
modified reservations for existing sessions.
3. Supporting various client Authentication Protocols 3. Supporting various client Authentication Protocols
In the operational model for this PIB, the Authentication Server is In the operational model for this PIB, the Authentication Server is
a specific function of the PDP. The main purpose of an a specific function of the PDP. The main purpose of the
authentication portions of this PIB is to verify the validity of authentication portions of this PIB is to verify the validity of
client credentials by an Authentiation Server. The verification client credentials by an Authentication Server. The verification
process itself may do this whilst ensuring some level of process itself may do this whilst ensuring some level of
authenticity, confidentiality and integrity. Messages exchanged authenticity, confidentiality and integrity. Messages exchanged
between a Client and Authentication Server (PDP) may remain between a Client and Authentication Server (PDP) may remain
confidential to PEP's and Proxy Servers. The message integrity may confidential to PEP's and Proxy Servers. The message integrity may
be ensured by some hashing algorithm so PEP's and Proxy's may be ensured by some hashing algorithm so PEP's and Proxy's may
inspect but not modify the content of authentication messages. inspect but not modify the content of authentication messages.
Clients, PEP's, Proxy's and PDP's will always need some security Clients, PEP's, Proxy's and PDP's will always need some security
method to ensure message authenticity. method to ensure message authenticity.
Weiss et al. Expires October 2000 [Page 19]
Some authentication protocols explicitly consider proxies by Some authentication protocols explicitly consider proxies by
allowing the payload to be carried over a variety of transports. allowing the payload to be carried over a variety of transports.
Others depend on the termination point of the connection to Others depend on the termination point of the connection to
explicitly proxy the authentication, when that is necessary. In explicitly proxy the authentication, when that is necessary. In
order to demonstrate the general utility of this model, a variety of order to demonstrate the general utility of this model, a variety of
client authentication protocols will be considered in this document. client authentication protocols will be considered in this document.
For each protocol, the negotiation mechanism will be described and For each protocol, the negotiation mechanism will be described and
the mapping to this framework will be detailed. the mapping to this framework will be detailed.
3.1. EAP Authentication 3.1. Provisioning
The PEP will not start an authentication sequence with the client if
it hasnĂt been told to do that. It will only do so when a specific
event occurs. The PDP tells the PEP exactly when this event should
be triggered. This process is called provisioning.
The provisioning starts with the initial Provisioning Request, which
is typically sent at boot time. The PEP sends up capability PRCĂs
indicating the types of authentication it can handle. The PDP will
reply by setting the following Access Bind PRCĂs:
a. dpeventHandler (datapathEventHandler)
b. dpEventhdlrAuthProtocol
c. eventHdlrElement
d. eventHdlrEventScope
e. eventHdlrHandleScope
f. contextData
and an additional PRC instance referred to by the
eventhdlrEventScopeFilter in the eventhdlrEventScope table,
indicating how the signaling trigger is recognized.
In case the PDP wants the PEP to perform an authentication when an
event is triggered, it should set dpeventhdlrRequestAuth in the
dpEventHdlr to true and optionally let the dpEventHdlrAuthProtocol
field point to a dpEventHdlrAuthProtocol to indicate which
authentication protocol should be used for the authentication.
As soon as the PDP has provisioned the PEP to watch for certain
traffic that triggers an event, the PEP is ready to start an
authentication.
3.2. EAP Authentication
The most significant aspect distinguishing EAP [EAP] from other The most significant aspect distinguishing EAP [EAP] from other
authentication protocols is that EAP assumes the negotiation is authentication protocols is that EAP assumes the negotiation is
between the client and the authentication server. In anticipation of between the client and the authentication server. In anticipation of
the fact that the terminating point of a connection such as PPP or the fact that the terminating point of a connection such as PPP or
L2TP is not necessarily the same as the agent managing client L2TP is not necessarily the same as the agent managing client
authentication, EAP encapsulates itĂs negotiation process in a authentication, EAP encapsulates itĂs negotiation process in a
separate header that can be forwarded in entirety to the server. separate header that can be forwarded in entirety to the server.
This mechanism provides extra security by preventing intermediate This mechanism provides extra security by preventing intermediate
proxies from monitoring or managing authentication credentials. proxies from monitoring or managing authentication credentials.
EAP supports a number of different authentication mechanisms EAP supports a number of different authentication mechanisms
including MD5, TLS, and One-Time-Password authentication. including MD5, TLS, and One-Time-Password authentication.
The terminology used in [EAP] differs from the terminology used in The terminology used in [EAP] differs from the terminology used in
this document. In particular, the peer, as defined in section 1.2 of this document. In particular, the peer, as defined in section 1.2 of
[EAP], is referred to as 'Client' in this document. Similar, the [EAP], is referred to as "Client" in this document. Similarly, the
'authenticator' is called a PEP in this document and 'back-end "authenticator" is called a PEP in this document and "back-end
server' is called the Authentication Server function of the PDP (or server" is called the Authentication Server function of the PDP (or
just PDP) in this document. just PDP) in this document.
3.1.1. EAP Message sequence 3.2.1. EAP Message sequence
The generic sequence of transmissions between the PEP and PDP has The generic sequence of transmissions between the PEP and PDP has
already been described in section 2. In particular, figure already been described in section 2. In particular, figure 2.1 gives
(reference to the figure on slide 3) gives an overview of the an overview of the messages involved between the Client workstation,
messages involved between the Client workstation, PEP and PDP. EAP PEP and PDP. EAP messages are embedded in PPP packets in the
messages are embedded in PPP packets in the communication between communication between the Client and the PEP. In the communication
the Client and the PEP. In the communication between the PEP and between the PEP and PDP, the EAP messages are embedded in COPS
PDP, the EAP messages are embedded in COPS Request, COPS Decision Request, COPS Decision and COPS Report messages. Figure 3.1 shows
and COPS Report messages. Figure 3.1 shows how EAP may be used to how EAP may be used to retrieve credentials from the client
retrieve credentials from the client workstation by the PDP. workstation by the PDP.
Weiss et al. Expires October 2000 [Page 20]
time time
| +---+ +---+ +---+ | +---+ +---+ +---+
| | | | |<- COPS-Dec Accessor -----| | | | | | |-- COPS-PRC exchange ---->| |
| | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | | | | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-EAP --| | | | | | |<- PPP LCP Req-EAP --| | | |
| | U |-- PPP LCP ACK-EAP ->| P | | P | | | U |-- PPP LCP ACK-EAP ->| P | | P |
| | s |<- PPP EAP Req Id ---| E | | D | | | s |<- PPP EAP Req Id ---| E | | D |
| | e |-- PPP EAP Res Id -->| P | | P | | | e |-- PPP EAP Res Id -->| P | | P |
| | r | | |-- COPS-Req Ses-EAP ---->| | | | r | | |-- COPS-Req Ses-EAP ---->| |
| | | | |<- COPS-Dec EAP Dec Chal -| | | | | | |<- COPS-Dec EAP Req Chal -| |
| | |<- PPP EAP Req Chal -| | | | | | |<- PPP EAP Req Chal -| | | |
| | |- PPP EAP Res Chal ->| | | | | | |- PPP EAP Res Chal ->| | | |
| | | | |- COPS-Rep EAP Rep Chal ->| | | | | | |- COPS-Rep EAP Res Chal ->| |
| | | | | | | | | | | | | |
| | | | |<- COPS-Dec Ses-Enable----| | | | | | |<- COPS-Dec EAP Success --| |
| | |<- PPP EAP succes ---| | | | | | |<- PPP EAP success --| | | |
V +---+ +---+ +---+ V +---+ +---+ +---+
Fig 3.1: Embedding of EAP messages between the Client workstation Fig 3.1: Embedding of EAP messages between the Client workstation
and the PEP, and between the PEP and PDP. The EAP messages may be and the PEP, and between the PEP and PDP. The EAP messages may be
opaque to the PEP. opaque to the PEP.
Typically, when the PEP boots up, it is configured with one or more Typically, when the PEP boots up, it sends itĂs capabilities to the
Accessor decisions specifying the criteria for generating an PEP PDP in a COPS message and is than configured by the PDP with one or
Access Request. The first message from the PEP to the PDP is a more datapathEventHandlers specifying the criteria for generating
request to initiate a new Session. The PEP sends a COPS request to PEP Event Messages. The first message after this provisioning
the PDP containing a new instance of the Session table. The process from the PEP to the PDP is a new Event Message. The PEP
sessionAccessor attribute in the Session table entry is a sends a COPS request to the PDP containing a new instance of the
ReferenceId that points to an AccessorTable entry indicating that Event table. The eventEventHdlr attribute in the Event table entry
EAP is a valid protocol to use in this Session. is a ReferenceId that points to a dpeventHandler entry indicating
(by means of the dpEventHdlrAuthProtocol) that EAP is a valid
When the Accessor has been configured to require authentication, a protocol to use for this Event. Also, the eventCause attribute in
PEP session request will not be generated until after a minimal set the Event table entry is a ReferenceId that points to an
of credentials have been negotiated with the client. For EAP, this eventhdlrElement indication of which Filter (by means of the
means that a PEP Access Request will not be generated until after eventhdlrEventScope) triggered the event.
the sessionRealm and sessionUsername have been determined. This
means that that the PEP must receive an EAP Identity Response
message before it can send the PEP Access Request.
Session table attribute Attribute type
------- -------
sessionId InstanceId
sessionStatus INTEGER
sessionRealm OCTET STRING
sessionUsername OCTET STRING
sessionDataPath Prid
sessionBinding ReferenceId
sessionAccessor ReferenceId
Figure 3.2: Data elements of the Session datastructure.
Weiss et al. Expires October 2000 [Page 21]
All EAP messages necessary to complete the authentication process All EAP messages necessary to complete the authentication process
will be forwarded to the PDP. With the exception of EAP Identity will be forwarded to the PDP. All of the negotiation occurs between
messages, the negotiation occurs between the Client and the PDP. In the Client and the PDP and should, except for the EAP message code
order to support multiple EAP protocols, this PIB supports a generic field, not be examined by the PEP. In order to support multiple EAP
EAP request class and EAP response class. Each class has a single protocols, this PIB supports a generic EAP request class and EAP
string attribute (authEapReqExtSpecific and authEapRespExtSpecific, response class. Each class has a single string attribute
respectively) within which the entire EAP message is passed. (authEapReqExtSpecific and authEapRespExtSpecific, respectively)
within which the entire EAP message is passed.
Although figure 3.1 shows two EAP messages going from the PDP to the Although figure 3.1 shows two EAP messages going from the PDP to the
Client and two EAP messages being returned from the client to the Client and two EAP messages being returned from the client to the
PDP, the actual number of messages exchanged can be any amount. The PDP, the actual number of messages exchanged can be any amount. The
PDP may continue to retrieve additional credentials from the client PDP may continue to retrieve additional credentials from the client
for as long as it wishes. As soon as the PDP has all the necessary for as long as it wishes. As soon as the PDP has all the necessary
credentials from the client, the PDP may continue to provision the credentials from the client, the PDP may continue to provision the
PEP with policies. This is action is not shown in figure 3.1. PEP with policies. This is action is not shown in figure 3.1.
The PDP should not end the EAP negotiation with an EAP Success or an The PDP should end the EAP negotiation with an EAP Success or an EAP
EAP Failure message. Instead, it must send a PDP Access Response, Failure message. If the PDP sends a EAP Success, the PEP must from
which takes the form of a COPS Decision. The PDP Access Response then on use the matchNext Prid to determine the next processing
contains the instance of the SessionTable with the SessionStatus set filter for data defined by the values described using the
to either ENABLED or DISABLED. The PEP must upon receipt of this eventhdlrEventScope.
COPS Decision message, send an EAP Success or EAP Failure to the
Client Workstation.
3.1.2. AuthEapReXXExt data structures 3.2.2. AuthEapReqExt and AuthEapRespExt data structures
The EAP messages are embedded in COPS by sending an instance of the The EAP messages are embedded in COPS by sending an instance of the
authEapReqExt or authEapRespExt table, which each have an attribute authEapReqExt or authEapRespExt table, which each have an attribute
(Specific) to encapsulate the appropriate EAP messages necessary for (Specific) to encapsulate the appropriate EAP messages necessary for
the authentication mechanism. The authEapReqExt table is owned and the authentication mechanism. The authEapReqExt table is owned and
managed by the PEP, while the authEapReqExt table is owned and managed by the PEP, while the authEapReqExt table is owned and
managed by the PDP. Put another way, the PDP generates authEapReqExt managed by the PDP. Put another way, the PDP generates authEapReqExt
instances that it sends in Decision messages and the PEP generates instances that it sends in Decision messages and the PEP generates
authEapRespExt instances that it sends in Report messages. Since authEapRespExt instances that it sends in Report messages. Since
neither the PEP nor the PDP needs to maintain the messages neither the PEP nor the PDP needs to maintain the messages
permanently, the same instance of each class is used when more than permanently, the same instance of each class is used when more than
one exchange is required in each direction. one exchange is required in each direction.
Since both AuthEapReqExt and AuthEapRespExt are extensions of the
AuthExt class, they both inherit the attributes of AuthExt.
AuthEapReXXExt table attributes Attribute type AuthEapReXXExt table attributes Attribute type
--------------- ------- ------------------------------- --------------
authExtId InstanceId authExtId InstanceId
authExtSession ReferenceId authExtEvent ReferenceId
authEapReXXExtSpecific OCTET STRING authEapReXXExtSpecific OCTET STRING
Fig 3.3: Data elements in AuthEapReqExt and AuthEapRespExt tables Fig 3.2: Data elements in AuthEapReqExt and AuthEapRespExt tables
The AuthEapReXXExt class contains three attributes. The instanceId The AuthEapReXXExt class contains three attributes. The instanceId
is used to uniquely define the instance in the table. However, since is used to uniquely define the instance in the table. However, since
EAP messages are meant to be opaque, they should not be referenced. EAP messages are meant to be opaque, they should not be referenced.
Because the purpose of the classes is to carry EAP messages and each Because the purpose of the classes is to carry EAP messages and each
Weiss et al. Expires October 2000 [Page 22]
message is transient instances of these tables are temporary and message is transient instances of these tables are temporary and
should not be referred to. The Session attribute points to the should not be referred to. The Event attribute points to the Event
Session table entry for which EAP is being negotiated. The format of table entry for which EAP is being negotiated. The format of EAP
EAP packages being passed by the AuthEapReXXExt classes is described packages being passed by the AuthEapReXXExt classes is described in
in [EAP]. [EAP].
3.2. PAP Authentication 3.3. PAP Authentication
PAP (Password Authentication Protocol), as described in section 2 of PAP (Password Authentication Protocol), as described in section 2 of
[AUTH] is a very simple authentication mechanism used over PPP. It [AUTH] is a very simple authentication mechanism used over PPP. It
is not considered to be a strong security mechanism, since it sends is not considered to be a secure mechanism, since it sends passwords
passwords over the wire in clear text format. However, where one- over the wire in clear text format. However, where one-time
time passwords are used, this security concern is mitigated. It is passwords are used, this security concern is mitigated. It is
described here nonetheless for illustration purposes and because it described here nonetheless for illustration purposes and because it
may still be used among ISPs, or in situations where another layer may still be used among ISPs, or in situations where another layer
already performs encryption for security. already performs encryption for security.
The terminology used in [AUTH] differs from the terminology used in The terminology used in [AUTH] differs from the terminology used in
this document. In particular, the peer as defined in section 1.2 of this document. In particular, the peer as defined in section 1.2 of
[AUTH] is referred to as 'Client' in this document. Similar, the [AUTH] is referred to as "Client" in this document. Similar, the
'authenticator' is called PEP in this document. "authenticator" is called PEP in this document.
3.2.1. PAP Connection sequence 3.3.1. PAP Connection sequence
Figure 3.4 shows how PAP may be used to retrieve credentials from Figure 3.3 shows how PAP may be used to retrieve credentials from
the client workstation by the PDP. the client workstation by the PDP.
time time
| +---+ +---+ +---+ | +---+ +---+ +---+
| | | | |<- COPS-Dec Accessor -----| | | | | | |-- COPS-PRC exchange ---->| |
| | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | | | | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-PAP --| | | | | | |<- PPP LCP Req-PAP --| | | |
| | U |-- PPP LCP ACK-PAP ->| P | | P | | | U |-- PPP LCP ACK-PAP ->| P | | P |
| | s |-- PPP PAP Id, Pwd ->| E | | D | | | s |-- PPP PAP Id, Pwd ->| E | | D |
| | e | | P |-- COPS-Req Ses-PAP ----->| P | | | e | | P |-- COPS-Req event, -->| P |
| | r | | | | | | | r | | |-- userPapExt -->| |
| | | | |<- COPS-Dec Ses-Enable ---| | | | | | | | |
| | | | |<- COPS-Dec eventElement -| |
| | | | |<- COPS-Dec authResult ---| |
| | |<- PPP PAP ack ------| | | | | | |<- PPP PAP ack ------| | | |
V +---+ +---+ +---+ V +---+ +---+ +---+
Fig 3.4: Embedding of PAP messages between the Client workstation Fig 3.3: Embedding of PAP messages between the Client workstation
and the PEP, and between the PEP and PDP. and the PEP, and between the PEP and PDP.
When the dpEventHandler has been configured to require
authentication, a PEP Event message will not be generated until
after a minimal set of credentials have been negotiated with the
client. For PAP, this means that a PEP Event Message will not be
generated until after the authRealm and authUsername have been
determined. This means that that the PEP must receive a PAP Identity
message before it can send the PEP Event Message.
The Client will send the Identity and Password to the PEP. The PEP The Client will send the Identity and Password to the PEP. The PEP
will embed the password into an AuthPapExtEntry datastructure and will embed the password into the userPapExt datastructure and send
send this to the PDP. In addition, the PAP identity attribute will this to the PDP. Since this datastructure inherits the fields of the
be inserted into the sessionUsername attribute of the Session entry. userAuthExt data structure and the extAuth data structure, it will
also contain the PAP identity attribute inserted into the
authUsername attribute of this Instance.
The first connection from the PEP to the PDP is a request to The first connection from the PEP to the PDP is an alert that an
initiate a new Session. The PEP sends a PEP Access Request to the event was triggered. The PEP sends an Event Message over COPS to the
PDP containing a new instance of the SessionTable. The PDP containing a new instance of the Event table. The eventEventHdlr
attribute in the Event table entry is a ReferenceId that points to a
dpeventHandler entry indicating (by means of the
dpEventHdlrAuthProtocol) that PAP is a valid protocol to use for
this Event. Also, the eventCause attribute in the Event table entry
is a ReferenceId that points to an eventhdlrElement indication which
Filter (by means of the eventhdlrEventScope) did trigger the event.
Along with this new instance of the Event table, the PEP must also
send an instance of the AuthPapExt table.
Weiss et al. Expires October 2000 [Page 23] Besides these required instances, the PEP might have been configured
sessionAccessor attribute in the Session table entry is a by the PDP to sent additional information about the client to the
ReferenceId that points to an AccessorTable entry indicating that PDP. For example in the case of a dialup connection between the
PAP is a valid protocol to use in this Session. Along with this new Client and the PEP, the PDP might specify using a contextData
instance of the Session table, the PEP must also send an instance of instance that the PEP should also sent an instance of a
the AuthPapExt table. ctxtDialupInterface.
3.2.2. AuthPapExtEntry datastructure The PDP performs the PAP authentication. When the authentication is
complete and the PDP is ready to authorize the event, the PDP
optionally provisions the PEP with policies. This sequence of
messages should terminate with a PDP Provisioning Decision (a COPS-
PR Decision message). The PDP Provisioning Decision contains an
instance of the AuthExtResult table with the authExtAuthSuccess set
to either TRUE or FALSE. The PEP must upon receipt of this COPS
Decision message, send PAP ACK or NACK message to the client. Also,
if the authExtAuthSuccess attribute was true, then the PEP should
keep track of this particular data, defined by the unique values of
the fields specified using the eventhdlrEventScope.
The PAP information is embedded in the PEP Access Request by sending 3.3.2. AuthPapExtEntry datastructure
an instance of the authPapExt table.
The PAP information is embedded in the PEP Event Message by sending
an instance of the authPapExt table. Since the authPapExt table is
an extension of the userAuthExt table, which is an extension of the
authExt table, the authPapExt inherits the attributes of these
tables.
AuthPapExt table attributes Attribute type AuthPapExt table attributes Attribute type
---------------- --------- --------------------------- --------------
authExtId InstanceId authExtId InstanceId
authExtSession ReferenceId authExtEvent ReferenceId
authRealm OCTET STRING
authUsername OCTET STRING
authPapExtPwd OCTET STRING authPapExtPwd OCTET STRING
Fig 3.5: Atributes of the AuthPapExt entry. Fig 3.4: Attributes of the AuthPapExt table.
The AuthPapExtEntry contains three attributes. The instanceId is The AuthPapExt contains five attributes. The instanceId is used to
used to uniquely define the instance in the table. However, since uniquely define the instance in the table. However, since the PAP
the PAP password is sent to the PDP once and is needed by neither password is sent to the PDP once and is needed by neither the PDP
the PDP nor the PEP after the client is authenticated, the instance nor the PEP after the client is authenticated, the instance should
should not be referenced after it is used the first time. The not be referenced after it is used the first time. The Event
Session attribute points to the Session table entry for which PAP is attribute points to the Event table entry for which PAP is being
being negotiated. negotiated.
The PDP performs the PAP authentication. When the authentication is The result of the authentication for PAP is sent in the
complete and the PDP is ready to authorize the session, the PDP may AuthExtResult table. Since the authExtResult table is an extension
optionally choose to provision the PEP with policies. This sequence of the AuthExt table, it inherits the attributes of AuthExt.
of messages should terminate with a PDP Access Decision (a COPS-PR
Decision message). The PDP Access Response contains the instance of
the Session table with the SessionStatus set to either ENABLED or
DISABLED. The PEP must upon receipt of this COPS Decision message,
send PAP ACK or NACK message to the client.
3.3. CHAP Authentication AuthExtResult table attributes Attribute type
------------------------------ --------------
authExtId InstanceId
authExtEvent ReferenceId
authExtAuthSuccess Truth Value
Fig 3.5: Attributes of the AuthExtResult table.
The AuthExtResult is sent by the PDP to the PEP. If the
authentication was successful and the PEP should from now on use the
matchNext Prid to determine the next processing filter (the next
component down the internal datapath in the PEP) for all traffic
defined by the values of the parameters as set in the
eventhdlrHandlerScope.
3.4. CHAP Authentication
CHAP (Challenge Authentication Protocol) [CHAP] is a strong CHAP (Challenge Authentication Protocol) [CHAP] is a strong
authentication mechanism, which eliminates the need to send authentication mechanism, which eliminates the need to send
passwords in the clear, like PAP does. With CHAP, the Authenticator passwords in the clear, like PAP does. With CHAP, the Authenticator
generates a challenge key, sends it to the Peer (Client) and the generates a challenge key, sends it to the Peer (Client) and the
client responds with a cryptographically hashed response that client responds with a cryptographically hashed response that
depends upon the Challenge and a secret key. The PDP checks the depends upon the Challenge and a secret key. The PDP checks the
secret key by performing the same encryption and comparing the secret key by performing the same encryption and comparing the
results. results.
The terminology used in [CHAP] differs from the terminology used in The terminology used in [CHAP] differs from the terminology used in
this document. In particular, the peer as defined in section 1.2 of this document. In particular, the peer as defined in section 1.2 of
[CHAP] is referred to as 'Client' in this document. Similar, the [CHAP] is referred to as "Client" in this document. Similar, the
'authenticator' is called PEP in this document. "authenticator" is called PEP in this document.
Weiss et al. Expires October 2000 [Page 24]
3.3.1. CHAP Connection sequence 3.4.1. CHAP Connection sequence
Figure 3.6 shows how CHAP may be used to retrieve credentials from Figure 3.6 shows how CHAP may be used to retrieve credentials from
the client workstation by the PDP. the client workstation by the PDP.
time time
| +---+ +---+ +---+ | +---+ +---+ +---+
| | | | |<- COPS-Dec Accessor -----| | | | | | |-- COPS-PRC exchange ---->| |
| | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | | | | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-CHAP -| | | | | | |<- PPP LCP Req-CHAP -| | | |
| | U |- PPP LCP ACK-CHAP ->| P | | P | | | U |- PPP LCP ACK-CHAP ->| P | | P |
| | s |<- PPP CHAP Chal ----| E | | D | | | s |<- PPP CHAP Chal ----| E | | D |
| | e |-- PPP CHAP Ident, ->| P | | P | | | e |-- PPP CHAP Ident, ->| P | | P |
| | r |-- Id, Resp ->| | | | | | r |-- Id, Resp ->| | | |
| | | | |-- COPS-Req Ses-CHAP ---->| | | | | | |-- COPS-Req event-CHAP -->| |
| | | | |-- COPS-Rep CHAP Resp, -->| | | | | | |-- COPS-Rep CHAP Resp, -->| |
| | | | |-- Chal -->| | | | | | |-- Chal -->| |
| | | | | | | | | | | | | |
| | | | |<- COPS-Dec Ses-Enable ---| | | | | | |<- COPS-Dec eventElement -| |
| | | | |<- COPS-Dec authResult ---| |
| | |<- PPP CHAP ack -----| | | | | | |<- PPP CHAP ack -----| | | |
V +---+ +---+ +---+ V +---+ +---+ +---+
Fig 3.6: Embedding of CHAP messages between the Client workstation Fig 3.6: Embedding of CHAP messages between the Client workstation
and the PEP, and between the PEP and PDP. and the PEP, and between the PEP and PDP.
As soon as the PEP finished negotiating CHAP as the Authentication As soon as the PEP finished negotiating CHAP as the Authentication
protocol, it generates a challenge itself, and sends this to the protocol, it generates a challenge itself, and sends this to the
Client. The client will respond to this authentication request by Client. The client will respond to this authentication request by
sending his or her identity, an identifier and the response. The sending his or her identity, an identifier and the response. The
response is a cryptographically encrypted hash based on the response is a cryptographically encrypted hash based on the
challenge and secret key (password). challenge and secret key (password).
The identifier is only used to keep track of CHAP messages, and The identifier is only used to keep track of CHAP messages, and
needs to be used by the PEP to recover the associated challenge. needs to be used by the PEP to recover the associated challenge.
The first connection from the PEP to the PDP is a request to The first connection from the PEP to the PDP is a notice of a new
initiate a new Session. The PEP sends a PEP Access Request to the Event. The PEP sends an Event Message to the PDP containing a new
PDP containing a new instance of the SessionTable. The instance of the Event Table. The eventEventHdlr attribute in the
sessionAccessor attribute in the Session table entry is a Event table entry is a ReferenceId that points to a dpeventHandler
ReferenceId that points to an AccessorTable entry indicating that entry indicating (by means of the dpEventHdlrAuthProtocol) that CHAP
CHAP is a valid protocol to use in this Session. Along with this new is a valid protocol to use for this Event. Also, the eventCause
instance of the Session table, the PEP must also send an instance of attribute in the Event table entry is a ReferenceId that points to
an eventhdlrElement indication of which Filter (by means of the
eventhdlrEventScope) did trigger the event. Along with this new
instance of the Event table, the PEP must also send an instance of
the AuthChapExt table. the AuthChapExt table.
Note that having the PEP issue the challenge allows the PEP to Note that having the PEP issue the challenge allows the PEP to
perpetrate fraud by issuing a replayed request (assuming that the perpetrate fraud by issuing a replayed request (assuming that the
PEP and PDP are in different domains). The only guard against this PEP and PDP are in different domains). The only guard against this
is for the PDP to check that multiple authentication requests for is for the PDP to check that multiple authentication requests for
the same client have unique challenges. This may be slow. PDP and the same client have unique challenges. This may be slow. PDP and
Authentication server developers that feel this is a security issue Authentication server developers who feel this is a security issue
Weiss et al. Expires October 2000 [Page 25]
may want to use EAP-MD5 authentication rather then CHAP may want to use EAP-MD5 authentication rather then CHAP
authentication, since EAP-MD5 addresses this problem by letting the authentication, since EAP-MD5 addresses this problem by letting the
PDP generate the challenge. PDP generate the challenge.
3.3.2. AuthChapExtEntry datastructure Besides these required instances, the PEP might have been configured
by the PDP to send additional information about the client to the
PDP. For example in the case of a dialup connection between the
Client and the PEP, the PDP might specify using a contextData
instance that the PEP should also sent an instance of a
ctxtDialupInterface.
The CHAP information is embedded in the PEP Access Request by The PDP performs the CHAP authentication. When the authentication is
sending an instance of the authChapExt table. complete and the PDP is ready to authorize the client, the PDP may
choose to provision the PEP with policies for this client, which was
probably the intention of starting this authentication process in
the first place. This sequence of messages should terminate with a
PDP Provisioning Decision (a COPS-PR Decision message). The PDP
Provisioning Decision contains an instance of the AuthExtResult
table with the authExtAuthSuccess set to either TRUE or FALSE. The
PEP must upon receipt of this COPS Decision message, send PAP ACK or
NACK message to the client. Also, if the authExtAuthSuccess
attribute was true, then the PEP should keep track of this
particular data, defined by the unique values of the fields
specified using the eventhdlrEventScope.
3.4.2. AuthChapExtEntry datastructure
The CHAP information is embedded in the Event Message by sending an
instance of the authChapExt table. Since the authChapExt table is an
extension of the userAuthExt table, which is an extension of the
authExt table, the authChapExt table inherits the attributes of
these tables.
AuthChapExt table attributes Attribute type AuthChapExt table attributes Attribute type
----------------- --------- ---------------------------- --------------
authExtId InstanceId authExtId InstanceId
authExtSession ReferenceId authExtEvent ReferenceId
authRealm OCTET STRING
authUsername OCTET STRING
authChapExtId Unsigned32 authChapExtId Unsigned32
authChapExtChal OCTET STRING authChapExtChal OCTET STRING
authChapExtResp OCTET STRING authChapExtResp OCTET STRING
Fig 3.7: Data elements of the AuthChapExtEntry datastructure. Fig 3.7: Data elements of the AuthChapExtEntry datastructure.
The AuthChapExtEntry contains four attributes. The instanceId is The AuthChapExtEntry contains seven attributes. The instanceId is
used to uniquely define the instance in the table. However, since used to uniquely define the instance in the table. However, since
the CHAP information is sent to the PDP once and is needed by the CHAP information is sent to the PDP once and is needed by
neither the PDP nor the PEP after the client is authenticated, the neither the PDP nor the PEP after the client is authenticated, the
instance should not be referenced after it is used the first time. instance should not be referenced after it is used the first time.
The Session attribute points to the Session table entry for which The Event attribute points to the Event table entry for which PAP is
PAP is being negotiated. being negotiated.
The challenge is the challenge generated by the PEP. The PDP may
check the challenge to see if it is different from challenges used
earlier. This to provides an increased level of security. The
Response and the Id is taken from the CHAP message sent by the
client and put into the AuthChapExtEntry by the PEP.
The PDP performs the CHAP authentication. When the authentication is The authChapExtChal attribute is the challenge generated by the PEP.
complete and the PDP is ready to authorize the session, the PDP may The PDP may check the challenge to see if it is different from
optionally choose to provision the PEP with policies for that challenges used earlier. This provides an increased level of
session. This sequence of messages should terminate with a PDP security. The Response and the Id is taken from the CHAP message
Access Decision (a COPS-PR Decision message). The PDP Access sent by the client and put into the AuthChapExtEntry by the PEP.
Response contains the instance of the Session table with the
SessionStatus set to either ENABLED or DISABLED. The PEP must upon
receipt of this COPS Decision message, send CHAP ACK or NACK message
to the client.
3.4. HTTP Authentication 3.5. HTTP Authentication
This section will be added in a subsequent version of this draft. This section will be added in a subsequent version of this draft.
Weiss et al. Expires October 2000 [Page 26]
4. Data Structures 4. Data Structures
The data classes defined formally in the Authentication PIB module The data classes defined formally in the Authentication PIB module
(section 7) are introduced and discussed here. (section 7) are introduced and discussed here.
4.1. Accessor class 4.1. Event class
The Accessor class models the accessor component in the PEP
discussed in section 2.1. An instance of this class, with the aid of
the objects to which it points, identifies when the PEP should send
an access (i.e. authorization) request to the PDP. As a result of
this request, a new session may be started. Hence, the Accessor can
be said to create or remove Session entries.
The Accessor is installed on the PEP by the PDP and references a
list of authentication protocols supported (AccessorAuthProtocol)
and a list of interface and header class identifiers whose instances
must be included in the PEP Access Request (the ContextData).
The attributes of the Accessor Class are as follows: Instances of this table represent events that occurred at the PEP.
The events reference the event handler instance and the specific
event handler element that the event was caught by.
AccessorId (InstanceId) The attributes of this class are:
identifies an instance of this class
AccessorRequestAuth (Boolean) eventId (InstanceId)
True if authentication is required Identifies this object
False if not.
AccessorAccElmRef (ReferenceId) eventEventHdlr (ReferenceId)
points to the AccessorElement object (sec. 4.2) for this This attribute allows a PEP to indicate to the PDP that this
Accessor event was generated due to the referenced Event Handler.
This attribute references an event handler via the
indirection PRC frwkReference, since the event handler and
event could potentially belong to a different PIB contexts.
AccessorAuthProtocol (TagReferenceId) eventCause (ReferenceId)
references AccessorAuthProtocol objects (sec. 4.4). There This attribute references the specific instance in a group
may be several AccessorAuthProtocol objects with this of event Handler elements belonging to an event Handler that
TagReferenceId. Each specifies one authentication protocol resulted in this event. This attribute references a specific
that may be used for client authentication in order to event handler element via the indirection PRC frwkReference,
satisfy the access request. since the event handler element and event could potentially
belong to a different PIB contexts.
AccessorAuthContext (TagReferenceId) 4.2. EventHandler class
references ContextData objects (sec. 4.5). There may be
several ContextData objects with this TagReferenceId. Each
specifies the PRI of one interface or header element class
for which an object instance must be included in access
requests triggered by this Accessor. This attribute must be
assigned a valid TagReferenceId when the AccessorRequestAuth
attribute is set to True.
AccessorDefaultDataPath (PRID) (optional) Instances of this PRC are provisioned by the PDP on the PEP to catch
points to the next data path element that will process out specific events. The Event Handlers reference a group of
of scope traffic ű that is not one of the following: eventHdlrElement PRIs that contain the scope of the event and
1. Traffic that is part of an established session. specify the context data to send to the PDP when an event is caught.
2. Traffic matching a pending session (one for which the PEP
Weiss et al. Expires October 2000 [Page 27] The attributes of the EventHandler Class are as follows:
is waiting for an access response).
3. A packet that triggers the creation of a session.
4.2. AccessorElement class eventHandlerId (InstanceId)
identifies an instance of this class
Generally speaking the purpose of the AccessorElement is to specify eventHandlerElements (TagReferenceId)
the characteristics of the Accessor. The attributes in the A reference to a group of eventHdlrElement instances, each
AccessorElement are there to provide maximal resuse by allowing of which determines the scope (criteria for generating a new
multiple instances of an Accessor to reuse the same AccessorElement request) and what context information to send in a request.
instance. AccessorElement object is referenced by an Accessor
object. It specifies a list of one or more AccessorSessionScope
objects, each of which defines a trigger for creating a Session
object and generating an access request. It also specifies what to
do with traffic for a newly created session while the PEP is
awaiting a response to the access request.
The attributes of the AccessorElement class are: eventHandlerNonMatchNext (Prid)
The data path for "out of scope" traffic that is not matched
by one of the eventHdlrElementĂs filter clauses.
AccessorElementId (InstanceId) 4.3. EventHdlrElement class
identifies the object
AccessorElementScope (TagReferenceId) The purpose of the EventHdlrElement is to specify the
references AccessorSessionScope objects (section 4.3). There characteristics of the EventHandler. The attributes in the
may be one or more AccessorSessionScope objects, each of EventHdlrElement provide maximal reuse by allowing multiple
which specifies conditions for creating a Session and instances of an EventHandler to reuse the same EventHdlrElement
generating an access request. instance. Each Instance of this PRC belongs to a group of
eventHdlrElement PRIs. The group is identified by the
eventHdlrElementGrpId attribute. These are provisioned by the PDP on
the PEP to catch specific events. This PRC contains the scope of the
event and specifies the context data type to send to the PDP when an
event is caught.
AccessorElementInterimFwdBehavior (Drop, Forward, Queue) Each EventHdlrElement constitutes a unique event semantic. Since the
specifies what to do with traffic for the newly created Event Scope, Handle Scope and Context Data are all bound to the
session while awaiting the response to the access request. EventHdlrElement, different EventHdlrElements can have different
Drop means to drop all packets received for this session Event Scope (matching rules), Handle Scope (Handle generation
until the PEP receives a PDP Access Response packet. Forward rules), and Context Data (event specific data passed with the Event
means forward interim traffic using the data path specified Message). This is why Event objects generated by the PEP reference
by the AccessorElementDefaultSessionDataPath attribute. both the Event Handler and the Event Handler Element that generated
Queue means to buffer interim traffic in a hold queue to be the event.
forwarded after access is granted by a PDP Access Response
packet.
This attribute provides for a great deal of flexibility One key aspect of the EventHdlrElement is the Event Criteria
regarding the treatment of interim traffic. For example, it attribute. This attribute is used to describe whether unique events
may be blocked altogether, it may be passed, but be given are one time events or repeatable events. For instance, every RSVP
best effort service, or it may be filtered to go only to a message may need to result in a Event Message. However, an Event
particular web server at which authentication will take Message may only be appropriate the first time a new Src IP address
place (see section 3.4) is seen. After that no events should be generated for that address.
However other new addresses should still generate Event Messages.
The Event Criteria attribute defines the frequency with which events
should be generated. If the Event Criteria is set to One_Time, only
one event will ever be generated for that EventHdlrElement when the
first match occurs, irrespective of the number of subsequent
matches. If the Event Criteria is set to Every_Time, each match will
result in an Event Message. A hybrid case is defined called
On_Change. This option allows a subset of the filter attributes to
be required for matching and a different set of attributes that must
from a unique n-tuple in order to generate an Event Message. See
Section 4.6 for more details of the behavior of the On_Change
attribute.
AccessorElementDefaultSessionDataPath (Prid) The EventHdlrHandleScope is optional. If it is not specified, itĂs
specifies the interim data path element that will process behavioral rules are taken from the EventHdlrEventScope objects
traffic for new sessions created by this accessor while associated with the relevant EventHdlrElement. In other words, the
awaiting an access response if the value of the criteria for generating Request Handles will be identical to the
AccessorElementInterimFwdBehavior attribute is Forward. criteria for generating Event Messages when the EventHdlrHandleScope
is not explicitly specified.
This attribute also specifies the default data path element The attributes of the EventHdlrElement class are:
that will process traffic for this session if no other
Weiss et al. Expires October 2000 [Page 28] eventHdlrElementId (InstanceId)
element is configured by the PDP. The value of this identifies the object
attribute will be used to initialize the value of the eventHdlrElementEventCriteria (Unsigned32)
SessionDataPath attribute of Session objects created by this Indicates when an event is generated. Valid options are
accessor. The PDP may subsequently override the one_time, every_time and on_change. This attribute allows
SessionDataPath attribute if it wishes with a PDP Access event Handlers to distinguish one time events (ignore after
Reponse message (Section 5.4). the first match) from recurring events (generate an event
every time a match occurs). An enum type is also define to
specify that a new event should be generated when a specific
set of fields change. This is important for protocols like
RSVP because messages are sent both to demonstrate that the
reservation is active and to notify hops of changes to
reservations. Since only changes need to propagate to the
PDP, the on_change option indicates that that events should
be generated selectively.
4.3. AccessorSessionScope class eventHdlrElementGrpId (TagId)
Group identifier. All instances with the same group
identifier belong to one group and can be referenced
collectively from an eventHandler instance.
The AccessorSessionScope class determines the criteria for eventHdlrElementEventScope (TagReferenceId)
generating a new unique session. FilterEntries as defined in the Identifies a group of eventHdlrEventScope entries associated
framework PIB [FWPIB] allow for the specification of the set of with this eventHdlrElement instance.
header fields that scope each session. Whenever traffic arrives at
the Accessor that is not part of an established session, it is
compared against the FilterEntry objects of the AccessorSessionScope
objects referenced by the AccessorElement. If it matches the
criteria specified in all of the FilterEntry objects, a new Session
object will be created and a PEP Access Request will be sent to the
PDP. For example, if a FilterEntry object specifies SRC IP address
(10.20.0.0) and SRC IP Mask (FF.FF.0.0) each new IP address within
the range 10.20.0.0 and 10.20.255.255 will trigger a new session.
Further after a session has been allocated for a specific SRC IP
address like 10.20.15.109, all subsequent traffic will be forwarded
from the Accessor to the data path assigned to the newly created
session.
When multiple fields are specified for the filter, each unique eventHdlrElementHandleScope TagReferenceId)
pairing of field values gets allocated a distinct session. For Identifies a group of eventHdlrHandleScope entries
example, if the SRC IP was assigned a range of 10.10.10.224 to associated with this eventHdlrElement instance. This is an
10.10.10.255 and DST Ports 80 to 90 then 10.10.10.240+80, optional attribute.
10.10.10.240+81, and 10.10.10.250+80 would all be assigned separate
sessions. The combination of supporting multiple filters and being
able to control precedence allows for the construction of both lists
(10.10.x.x and 10.15.x.x) and combinations of disjoint headers in a
single match criteria (any combination of 10.10.x.x and VLANs 100 to
120).
The attributes of this class are: eventHdlrElementContext (TagReferenceId)
Identifies a list of ContextDataTable entries associated
with this eventHdlrElement instance.
AccessorSessionScopeId (InstanceId) eventHdlrElementMatchNext (Prid)
identifies this object The data path for traffic in scope.
AccessorSessionScopeGroup (TagId) 4.4. EventHdlrEventScope class
contains the tag by which the AccessorElement references
this object. It is the means by which a list of filters can
be associated with a Accessor
AccessorSessionScopeFilter (PRID) This PRC defines the scope of an event handler element using
points to a FilterEntry object (as defined in the Framework references to filters defined in the Framework PIB or in some other
PIB) that specifies the filter for this AccessorSessionScope PIBs. These filters may describe specific protocol properties for
object which events need to be generated. These filter references are
grouped using a TagId, and this group is then referenced from the
eventHdlrElement PRC.
Weiss et al. Expires October 2000 [Page 29] Whenever traffic arrives at the EventHandler for which an Event
AccessorSessionScopePrecedence (Integer) Message has not already been generated, it is compared against the
specifies how multiple FilterEntry objects interact FilterEntry objects of the EventHdlrEventScope objects referenced by
the EventHdlrElement. If it matches the criteria specified in all of
the FilterEntry objects, a new Event Message is generated and sent
to the PDP. The value of EventHdlrElementĂs EventCriteria attribute
in conjunction with the value of the Event Scope classĂs ChangeFlag
attribute determine whether an Event Message will be generated.
4.4. AccessorAuthProtocol class For example, if a FilterEntry object specifies SRC IP address
(10.20.0.0) and SRC IP Mask (FF.FF.0.0) and the EventCriteria is set
to One_Time, the first address in the range of 10.20.0.0 and
10.20.255.255 will generate an event and no events will follow. If
the EventCriteria is set to Every_Time for the same attribute
settings, each time a packet contains an IP address within the range
an Event Message will be generated. If the EventCriteria is set to
On_Change and the eventHdlrEventScopeChangeFlag is set to True, each
new IP address within the range 10.20.0.0 and 10.20.255.255 will
trigger a new Event Message. However, as soon as a specific Src IP
address like 10.20.15.109 has generated an Event Message, that
specific address will no longer generate an event. If the
EventCriteria is set to On_Change and the
eventHdlrEventScopeChangeFlag is set to False for the example
address range, than the eventHdlrEventScope instance with the
ChangeFlag set to True will determine uniqueness. In this scenario,
the address range is acting as a strict filter that must be met
without regard to which address in the range is responsible or
whether that address has been seen previously.
The AccessorAuthProtocol class allows a PDP to configure the set of When multiple fields are specified for the filter and the ChangeFlag
authentication protocols that are allowed for a given Accessor. The is set to true, each unique combination of field values generates an
instances of this class are grouped together using the same TagId event. For example, if the SRC IP is assigned a range of
value, the reference to which are specified in the Accessor. 10.10.10.224 to 10.10.10.255 and DST Ports 80 to 90 then
10.10.10.240+80, 10.10.10.240+81, and 10.10.10.250+80 would all
generate separate events. The combination of supporting multiple
filters and being able to control precedence allows for the
construction of both lists (10.10.x.x and 10.15.x.x) and
combinations of disjoint headers in a single match criteria (any
combination of 10.10.x.x and VLANs 100 to 120). See Section 4.6 for
a detailed example of filter construction.
The attributes of this class are: The attributes of this class are:
AccessorAuthProtocolId (InstanceId) eventHdlrEventScopeId (InstanceId)
identifies this object Identifies this object
AccessorAuthProtocolGroup (TagId)
contains the tag by which the Accessor references this
object.
AccessorAuthProtocolAuthMechanism (Enum)
specifies an authentication mechanism to be used in access
requests triggered by the Accessor referencing this
AccessorAuthProtocol object. The value is from an enumerated
list initially consisting of (PAP, CHAP, EAP-MD5, and EAP-
TLS)
4.5. ContextData class
The ContextData class defines the set of interface descriptions or
packet header data that should be included in each PEP Access
Request for sessions created by the reference Accessor. There may be
multiple objects of this class referenced with a tag by an Accessor
object.
Note that the ContextData class can be part of either an Accessor
Provisioning decision message (Section 5.1) or a Session-specific
ContextData Request message (Section 5.5).
The attributes of this class are: eventHdlrEventScopeGroup (TagId)
Contains the tag by which the EventHdlrElement references
this object. This is the means by which a list of filters
can be associated with an EventHandler.
ContextDataId (InstanceId) eventHdlrEventScopeFilter (PRID)
identifies this object Points to a FilterEntry object (as defined in the Framework
PIB) that specifies the filter for this EventHdlrEventScope
object
ContextDataGroup (TagId) eventHdlrEventScopePrecedence (Integer)
contains the tag by which an Accessor object references Represents the precedence of this criterion with respect to
objects of this class. This attribute may only be set for other criteria within the same group. When the precedence is
ContextData instances that will be bound to an Accessor. If unique, the instance represents an alternative criterion (an
the ContextData instance will be used in a Session-specific OR function). When the precedence for two or more instances
ContextData Request, this attribute must be left of the eventHdlrEventScope class is the same, the attributes
unspecified. within all the instances are treated collectively as a
single filter criteria.
Weiss et al. Expires October 2000 [Page 30] eventHdlrEventScopeChangeFlag (TruthValue)
ContextDataSessionRef (ReferenceId) Boolean value, if set to "True" indicates that a new event
points to a Session object. This attribute may only be used should be generated if any of the assigned fields in the
for ContextData instances that will be used in a Session- associated filter change.
specific ContextData Request. This attribute must be left
unspecified for instances of ContextData instances bound to
specific Accessors.
ContextDataIfElement (PRC of interface elements) 4.5. EventHdlrHandleScope class
identifies an interface or header class identifier whoĂs
class instance must be populated by the PEP and included in
an access request or a Session-specific ContextData Request.
ContextDataEncapsulation (Integer) This PRC defines the scope of Request Handles generated by the PEP
distinguishes inner and outer headers of tunnels. For due to events caught by the Event Handler Element. Each instance of
example, the PRC of a header element may specify that layer this PRC references filters defined in the Framework PIB or some
3 header information should be sent. When there are tunnels, other signaling-protocol specific filter PRCs. These filters may
however, there will be header contents (with different IP describe specific protocol properties to which this Event Handler is
addresses) for the outer header than for the inner header. sensitive. Essentially this table defines when a new COPS Request
Handles must be created by the PEP based on protocol properties. The
Event Handler may be set up to be sensitive to specific field values
and/or the uniqueness of a set of values considered together. This
accommodates various behaviors of signaling protocols. These filter
references are grouped using a TagId, and this group is then
referenced from the eventHdlrElement PRC via the
eventHdlrElementHandleScope TagReference.
A value of zero means return all layers of header. A The behavior of the EventHdlrHandleScope class is identical to the
negative n means return the nth layer from the innermost behavior of the EventHdlrEventScope. The only difference is the
header. A positive n means return the nth layer from the EventHdlrEventScope determines when new Events are created and the
outermost header. EventHdlrHandleScope determines when new COPS Request Handles are
created. It is important to note that the attributes determining
when a new Handle is created MUST be a subset of the filter
attributes and filter values specified for the EventHdlrEventScope.
The reason for this is that an Event Message MUST use one of the
available Request Handles to notify the PDP of an Event. If the
attributes and values used in the EventHdlrEventScope are not a
superset of the attributes and values EventHdlrHandleScope, then
there may be no valid Handle over which the Event Message can be
sent to the PDP.
In situations where the ContextData is explicitly bound to an The EventHdlrHandleScope is optional. If it is not specified, itĂs
Accessor table entry, the ContextDataGroup attribute (TagId) must be behavioral rules are taken from the EventHdlrEventScope objects
specified and the ContextDataSessionRef (ReferenceId) must be Null. associated with the relevant EventHdlrElement. In other words, the
When this class is used to get specific information for a session, criteria for generating Request Handles will be identical to the
the ContextDataSessionRef is used and the ContextDataGroup is Null. criteria for generating Event Messages when the EventHdlrHandleScope
Under no circumstances may an instance of the ContextData class have is not explicitly specified.
both the ReferenceId and the TagId specified.
For examples of classes that may be referenced by the ContextData See Sections 4.3 and 4.6 for more details on the operational
class, see section 4.8. behavior of this class.
4.6. Session class eventHdlrHandleScopeId (InstanceId)
An arbitrary integer index that uniquely identifies an instance of
the eventHdlrHandleScopeTable class.
Each instance of the Session class represents a session on the PEP. eventHdlrHandleScopeGroup (TagId)
The PEP creates an instance of this class and sends it in the PEP Represents the binding between the eventHdlrElementEntry and the
Access Request to the PDP. In the PDP Access Response, the PDP sends eventHdlrHandleScope entries. A group of eventHdlrHandleScope
a success/fail decision back to the PEP. This decision contains the entries constitutes the criteria for defining the scope of the
same instance of the Session class, with its SessionStatus field Handles generated.
filled in to indicate the outcome of the authorization decision.
Note that the owner of the Session Class is always the PEP and the
PEP always assigns the Instance ID.
Sessions may be linked to each other, meaning that a new session may eventHdlrHandleScopeFilter (Prid)
be initiated within the context of an existing session. This Pointer to a filter to be used as the criteria.
possible dependency is reflected in the Session class.
The attributes of the Session class are: eventHdlrHandleScopePrecedence (INTEGER)
Represents the precedence of this criterion with respect to other
criteria within the same group. When the precedence is unique, the
instance represents an alternative criteria (an ORing function).
When the precedence for two or more instances of the
eventHdlrHandleScope class is the same, the attributes within all
the instances are treated collectively as a single filter criteria.
SessionId (InstanceId) eventHdlrHandleScopeChangeFlag (TruthValue)
Boolean value, if set to "True" indicates that a new Handle should
be generated if any of the assigned fields in the associated filter
change.
Weiss et al. Expires October 2000 [Page 31] The PDP installs EventHandlerElements as part of constructing the
identifies this object event handler. EventHandlerElements describe when events will be
generated and which COPS request handles will be used to send the
requests.
SessionStatus (Integer) 4.6. Behavior of the Event and Handle Scope classes
set by the PDP. Indicates whether this access attempt is
authorized (success) or unauthorized (fail) or whether an
authorization decision is still pending.
SessionRealm (Octet String) The rules for interpreting Handle Scope and Event Scope are the
the realm field of the clientĂs Network Access Identifier same. One is applied to Handles and the other is applied to Events.
[NAI]. SessionRealm tells the PDP in what administrative
domain the client can be authenticated. This attribute is
optional, but must be provided if the AccessorRequestAuth
attribute of the Accessor object is set to true and the
specific authentication protocol supports realms.
SessionUsername (Octet String) Each scope class (Event Scope or Handle Scope) instance has a
the Username field of the clientĂs NAI [NAI]. The precedence value associated with it. When two or more scope class
SessionUsername attribute identifies the client for which instances of the same type (event vs handle) have the same
this Session is being created. SessionUsername is optional, precedence number, they are considered part of the same rule. For
but must be specified if the RequestAuthentication attribute example, the table below lists a set of Event Scope class instances,
of the Accessor is set to true. their precedence values and the filter field names and values
associated with each instance: (FName is the field name)
SessionDataPath (PRID) Instance Precedence FName/Val FName/Val FName/Val
points to the first data path element to process traffic for -------- ---------- --------- --------- ---------
this session. SessionDataPath is initialized by the PEP to 1* 2 W/20 X/2-4
the value of the AccessorElementDefaultSessionDataPath 2* 1 A/5-6 B/15 C/10-11
attribute of the AccessorElement object. The PDP may assign 3 2 W/14 Y/500-550
a different value before returning the Session object in the 4 2 Q/4-9 R/92
PDP Access Response message. This example would result in events being generated when one of the
two expressions below are matched:
1. (A=5 or A=6) and (B=15) and (C=10 or C=11 or C=12)
2. (W=20 or W=14) and (X=2-4) and (Y=500-550) and (Q=4-9) and (R=92)
SessionBinding (ReferenceId) If the EventCriteria was set to "OneTime", then if either 1 or 2 is
If this is a daughter session of another session, the matched, one event will be generated and this particular Event
SessionBinding attribute points to the parent session. Handler Element will generate no further events. Note that if
A hierarchy of sessions is useful where a client has already matches occur but the "OneTime" event has already been generated,
initiated a session but later wants to access a service for the Event Hander Element's MatchNext attribute may still determine
which further authorization is needed. An Accessor can be what the next forwarding action is for the packet event thought no
created by the PDP in the data path of the parent session to event is generated.
trigger when additional service is required. A daughter
session is created that points back to the parent session.
An access request message is sent by the PEP to the PDP to
authorize the new service. Authentication may or may not be
required to establish the daughter session.
SessionAccessor (ReferenceId) If the EventCriteria was set to "EveryTime", then every matching
points to the Accessor which created this Session packet will cause an event. If the EventCriteria was set to
"OnChange", then events will be generated the first time a unique
combination of attributes is seen. Setting the ChangeFlag in the
EventScope class (denoted by the asterisks in the previous example),
identifies the set of attributes for which unique combinations of
values generated new events.
4.7. AuthExt class Continuing the example above the following table shows a stream of
packets and whether an event will be generated.
The AuthExt class contains authentication data passed between the 1. A=5, B=19, C=10 No Event (B did not match)
PDP and the client such as challenges and responses. An instance of 2. A=5, B=15, C=10 Event (Unique pairing of A & C)
this class must be included with a Session class instance in a PEP 3. A=6, B=15, C=11 Event (Unique pairing of A & C)
Access Request when the AccessorRequestAuth attribute in thee 4. W=20, X=2, Y=500, Q=4, R=92 Event (Unique pairing of W & X)
Accessor managing the session is set to True. 5. W=20, X=2, Y=505, Q=9, R=92 No Event (Already have a
matched for W & X)
6. A=5, B=15, C=11 Event (Unique pairing of A & C)
7. A=5, B=15, C=10 No Event (Already have a
matched for A & C)
Weiss et al. Expires October 2000 [Page 32] 4.7. EventHdlrAuthProtocol class
The data in this class is passed between the PDP and the client with
little or no involvement of the PEP except to forward it in the
appropriate AuthExt class instance. The PEP is not meant to store
AuthExt objects. As such, this class, along with all its extending
classes, is meant to be 'transient'. Its instances are temporary and
are deleted by the PEP after a certain time or event. The PDP, in
its decisions, must not refer to instances of this class that are
sent by the PEP in its requests. Likewise, the PEP must not refer to
instances sent by the PDP. Also, since instances are deleted, it is
possible for InstanceIds to be reused.
The AuthExt class is extended for each authentication mechanism This
supported. As a base class, it is never instantiated. class allows a PDP to configure the set of authentication mechanisms
that are allowed for users or devices that must authenticate in
order to have access policies assigned to them.
The attributes of this class are: The attributes of this class are:
AuthExtId (InstanceId) EventHdlrAuthProtocolId (InstanceId)
identifies this object Identifies this object
AuthExtSession (ReferenceId)
points to the Session for which this object contains
authentication information
4.7.1. AuthEapReqExt class
The AuthEapReqExt class extends the AuthExt class. It contains an
EAP message. (See sec. 3.1.) Instances of this class are sent by the
PDP to the PEP.
The attributes that this class adds to the base class are:
AuthEapReqExtSpecific (Octet String)
an EAP message [EAP] passed from the PDP to the client via
the PEP in a COPS-PR Decision message.
4.7.2. AuthEapRespExt class
The AuthEapRespExt class extends the AuthExt class. It contains an EventHdlrAuthProtocolGroup (TagId)
EAP message. (See sec. 3.1.) Instances of this class are sent by the Represents a binding between an datapathEventHdlrTable
PEP to the PDP. instance and a list of eventHdlrAuthProtocolTable instances.
The attributes that this class adds to the base class are: EventHdlrAuthProtocolAuthMechanism (Enum)
Specifies an authentication mechanism to be used in Event
Messages triggered by the EventHandler referencing this
EventHdlrAuthProtocol object. The value is from an
enumerated list initially consisting of (PAP, CHAP, EAP-MD5,
and EAP-TLS)
AuthEapRespExtSpecific (Octet String) 4.8. DatapathEventHdlr Class
an EAP message [EAP] passed from the client to the PDP via This PRC is an extension of the EventHandler PRC. This extension
the PEP in a COPS-PR Report message. illustrates the use of the EventHandler PRC concept for
authentication usage. Instances of this PRC are provisioned by the
PDP on the PEP to catch specific events that require authentication
processing. This PRC references a group of eventHdlrAuthProtocol
instances that define a set of Authentication mechanisms to use if
an access event is caught by this event Handler. From its base class
(Event Handler) this PRC also references a group of eventHdlrElement
PRIs that contain the scope of the access event and specify the
context data to send to the PDP when an access event is caught.
4.7.3. AuthPapExt class The attributes of this class are:
datapathEventHdlrRequestAuth (TruthValue)
Boolean flag, if set to "True" requires authentication data
to be sent in the Event Message sent to the PDP.
The AuthPapExt class extends the AuthExt class. It contains the PAP datapathEventHdlrAuthProtocol (TagReferenceId)
Password. (See sec. 3.2.) References a group of eventHdlrAuthProtocol instances, each
of which specifies an authentication mechanism.
Weiss et al. Expires October 2000 [Page 33] 4.9. ContextData class
The attributes that this class adds to the base class are:
AuthPapExtPwd (Octet String) This PRC specifies the context information to send to the PDP when
a one-time password used to authenticate the client an event is caught. The context information to send is described in
terms of the PRC data types to include in the request, the level of
encapsulated data and the interface information for that request.
4.7.4. AuthChapExt class The attributes of this class are:
The AuthChapExt class extends the AuthExt class. It contains the ContextDataId (InstanceId)
attributes of the CHAP protocol [CHAP]. (See section 3.3.) Identifies this object
The attributes that this class adds to the base class are: ContextDataGroup (TagId)
Defines the grouping of contextData instances that are
applicable to a given eventHdlrElement.
AuthChapExtId (Unsigned32) ContextDataIfElement (PrcIdentifier)
The AuthChapExtId is generated by the PEP. The ID value is The OID of a class whose instance is to be included with
sent to the client. When the client endpoint (Peer) the PEP request or event-specific ContextData Response.
generates a CHAP response it includes the same ID, and the
ID is then included in this attribute when it is sent to the
PDP.
AuthChapExtChal (Octet String) ContextDataEncapsulation (Integer)
The AuthChapExtChal is generated by the PEP. The Challenge This attribute allows one to distinguish between inner and
value is sent to the client, along with the ID. When the outer headers when there are multiple encapsulated headers
client generates a CHAP response containing the ID and of the same type in a packet.
Response (key), the Challenge associated with the ID is
included in this attribute when it is sent to the PDP.
AuthChapExtResp A value of:
The Response is calculated by the client and forwarded by 0 means all headers,
the PEP to the PDP. positive number 'n' means the 'n'th header starting
from the outermost,
negative number 'n' means the 'n'th header starting from
the innermost.
4.8. ContextData classes 4.10. ContextData classes
This section contains examples of classes that might be referenced This section contains examples of classes that might be referenced
by the ContextData class as classes that must be included in the by the ContextData class as classes that must be included in the
access request for various types of accessors. Event Message for various types of eventHdlrElements.
There are two kinds of ContextData classes depending on the type of There are two kinds of ContextData classes depending on the type of
PEP. Some PEPs receive traffic from many users over a shared port PEP. Some PEPs receive traffic from many users over a shared port
such as an Ethernet port. They recognize new users based on such as an Ethernet port. They recognize new users based on
information in the headers of incoming packets. For them, the information in the headers of incoming packets. For them, the
ContextData will come from packet headers. The L3HeaderData class ContextData will come from packet headers. The L3HeaderData class
is an example of this kind of ContextData class. Other PEPs receive is an example of this kind of ContextData class. Other PEPs receive
traffic from one user per interface. For them, the context data traffic from one user per interface. For them, the context data
will be information about the interface. The will be information about the interface. The
CtxtDialupInterfaceFramedProtocol class is an example of this kind CtxtDialupInterfaceFramedProtocol class is an example of this kind
of ContextData class. of ContextData class.
4.8.1. CtxtL3Hdr class 4.10.1. CtxtL3Hdr class
This class specifies level three header data. This class is used to This class specifies level three header data. This class is used to
inform the PDP of the details of the IP header that caused the PEP inform the PDP of the details of the IP header that caused the PEP
Access Request to be generated. Event Message to be generated.
Weiss et al. Expires October 2000 [Page 34]
The attributes of this class are: The attributes of this class are:
CtxtL3HdrId (InstanceId) CtxtL3HdrId (InstanceId)
identifies this object identifies this object
CtxtL3HdrSrcAddrType (Enum) CtxtL3HdrSrcAddrType (Enum)
specifies the type of the packetĂs layer 3 source address specifies the type of the packetĂs layer 3 source address
CtxtL3HdrSrcAddr CtxtL3HdrSrcAddr
the packetĂs layer 3 source address the packetĂs layer 3 source address
skipping to change at line 1745 skipping to change at page 33, line 21
Indicates whether this packet is ECN capable (True) or not Indicates whether this packet is ECN capable (True) or not
(False) (False)
CtxtL3HdrIpOpt CtxtL3HdrIpOpt
IP Options IP Options
CtxtL3HdrEncap CtxtL3HdrEncap
The Encap allows the PEP to indicate where this header is in The Encap allows the PEP to indicate where this header is in
relation to other IP headers found in the packet (with relation to other IP headers found in the packet (with
tunnels). This value can be either positive or negative tunnels). This value can be either positive or negative
depending on how the Accessor (or the Session-specific depending on how the EventHandler (or the Session-specific
Context Data request) was specified using negative or Context Data request) was specified using negative or
positive numbers. positive numbers.
A negative n means return the nth layer from the innermost A negative n means return the nth layer from the innermost
header. A positive n means return the nth layer from the header. A positive n means return the nth layer from the
outermost header. outermost header.
Weiss et al. Expires October 2000 [Page 35] 4.10.2. Ctxt802Hdr class
4.8.2. Ctxt802Hdr class
This class specifies IEEE 802.1 header data. This class is used to This class specifies IEEE 802.1 header data. This class is used to
inform the PDP of the details of the 802 header that caused the PEP inform the PDP of the details of the 802 header that caused the PEP
Access Request to be generated. Event Message to be generated.
The attributes of this class are: The attributes of this class are:
Ctxt802HdrId (InstanceId) Ctxt802HdrId (InstanceId)
identifies this object identifies this object
Ctxt802HdrSrcAddr Ctxt802HdrSrcAddr
the frameĂs source MAC address the frameĂs source MAC address
Ctxt802HdrDstAddr Ctxt802HdrDstAddr
skipping to change at line 1782 skipping to change at page 34, line 4
Ctxt802HdrProtocol Ctxt802HdrProtocol
the layer 2 frameĂs protocol field the layer 2 frameĂs protocol field
Ctxt802HdrPriority Ctxt802HdrPriority
the layer 2 frameĂs priority field (only used if the frame the layer 2 frameĂs priority field (only used if the frame
is using the 802.q header extension) is using the 802.q header extension)
Ctxt802HdrVlan Ctxt802HdrVlan
the layer 2 frameĂs VLAN field (only used if the frame is the layer 2 frameĂs VLAN field (only used if the frame is
using the 802.q header extension) using the 802.q header extension)
Ctxt802HdrEncap Ctxt802HdrEncap
The Encap allows the PEP to indicate where this header is in The Encap allows the PEP to indicate where this header is in
relation to other IP headers found in the packet (with relation to other IP headers found in the packet (with
tunnels). This value can be either positive or negative tunnels). This value can be either positive or negative
depending on how the Accessor (or the Session-specific depending on how the Event Handler (or the explicitly
Context Data request) was specified using negative or requested PDP Context Data request) was specified using
positive numbers. negative or positive numbers.
A negative n means return the nth layer from the innermost A negative n means return the nth layer from the innermost
header. A positive n means return the nth layer from the header. A positive n means return the nth layer from the
outermost header. outermost header.
4.8.3. CtxtDialupInterface class 4.10.3. CtxtDialupInterface class
The CtxtDialupInterface class specifies data to be included in The CtxtDialupInterface class specifies data to be included in Event
access requests sent by accessors providing dialin services. Messages sent by Event Handlers providing dialin services.
The attributes of this class are: The attributes of this class are:
CtxtDialupInterfaceId CtxtDialupInterfaceId
identifies this object identifies this object
CtxtDialupInterfaceNASPort CtxtDialupInterfaceNASPort
This attribute indicates the physical port number of This attribute indicates the physical port number of
Weiss et al. Expires October 2000 [Page 36]
the NAS which is authenticating the user. Note that this is the NAS which is authenticating the user. Note that this is
using 'port' in its sense of a physical connection on the using 'port' in its sense of a physical connection on the
NAS, not in the sense of a TCP or UDP port number. Either NAS, not in the sense of a TCP or UDP port number. Either
CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortType CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortType
or both SHOULD be specified in a CtxtDialupInterface object, or both SHOULD be specified in a CtxtDialupInterface object,
if the NAS if the NAS differentiates among its ports.
differentiates among its ports.
CtxtDialupInterfaceNASPortId CtxtDialupInterfaceNASPortId
This attribute contains a text string which identifies the This attribute contains a text string which identifies the
port of the NAS which is authenticating the user. Note that port of the NAS which is authenticating the user. Note that
this is using 'port' in its sense of a physical connection this is using 'port' in its sense of a physical connection
on the NAS, not in the sense of a TCP or UDP port number. on the NAS, not in the sense of a TCP or UDP port number.
Either CtxtDialupInterfaceNasPort or Either CtxtDialupInterfaceNasPort or
CtxtDialupInterfaceNasPortId SHOULD be specified in a CtxtDialupInterfaceNasPortId SHOULD be specified in a
CtxtDialupInterface object, if the NAS differentiates among CtxtDialupInterface object, if the NAS differentiates among
its ports. CtxtDialupInterfaceNasPortId is intended for use its ports. CtxtDialupInterfaceNasPortId is intended for use
skipping to change at line 1853 skipping to change at page 35, line 20
(ANI) or similar technology. (ANI) or similar technology.
CtxtDialupInterfaceConnectInfo CtxtDialupInterfaceConnectInfo
This attribute is sent from the NAS to indicate the This attribute is sent from the NAS to indicate the
nature of the user's connection. nature of the user's connection.
This is a notify-only class. These attributes are not write-able by This is a notify-only class. These attributes are not write-able by
the PDP. the PDP.
Three additional notify/install classes can be defined. These Three additional notify/install classes can be defined. These
classes can be included in an access request as information to the classes can be included in an Event Message as information to the
PDP. The PDP may change the values of these attributes, however, in PDP. The PDP may change the values of these attributes, however, in
subsequent provisioning messages. subsequent provisioning messages.
4.8.3.1 CtxtDialupIfFramedProtocol class 4.10.4 CtxtDialupIfFramedProtocol class
The CtxtDialupIfFramedProtocol class is an optional class that may The CtxtDialupIfFramedProtocol class is an optional class that may
be sent if a framed protocol is being used. be sent if a framed protocol is being used. This class MAY be
specified in the ContextData PRC by the PDP in a decision message if
Weiss et al. Expires October 2000 [Page 37] the PDP needs this context information (if it was not already setup
to be sent in the eventHandler). It MUST be sent up to the PDP in a
request message if it is specified via the ContextData PRC in an
eventHandler.
The attributes of this class are: The attributes of this class are:
CtxtDialupIfFramedProtocolId CtxtDialupIfFramedProtocolId
identifies this object identifies this object
CtxtDialupIfFramedProtocolProt CtxtDialupIfFramedProtocolProt
This attribute indicates the framing to be used for This attribute indicates the framing to be used for
framed access. framed access.
CtxtDialupIfFramedProtocolMTU CtxtDialupIfFramedProtocolMTU
This attribute indicates the Maximum Transmission Unit to be This attribute indicates the Maximum Transmission Unit to be
configured for the user, when it is not negotiated by some configured for the user, when it is not negotiated by some
other means (such as PPP). It MAY be used in access other means (such as PPP).
response packets. It MAY be used in an access request
packet as a hint by the NAS to the PDP that it would prefer
that value, but the PDP is not required to honor the hint.
CtxtDialupIfFramedProtocolCompression (Enum) CtxtDialupIfFramedProtocolCompression (Enum)
This attribute indicates a compression protocol to be used This attribute indicates a compression protocol to be used
for the link. It MAY be used in access response packets. for the link.
It MAY be used in an access request packet as a hint to the
PDP that the NAS would prefer to use that compression, but
the PDP is not required to honor the hint.
CtxtDialupIfFramedProtocolPortLimit CtxtDialupIfFramedProtocolPortLimit
This attribute sets the maximum number of ports to be This attribute sets the maximum number of ports to be
provided to the user by the NAS. This Attribute MAY be sent provided to the user by the NAS. It is intended for use in
by the PDP to the PEP in an access response packet. It is conjunction with Multilink PPP or similar uses.
intended for use in conjunction with Multilink PPP or
similar uses. It MAY also be sent by the NAS to the PDP as
a hint that that many ports are desired for use, but the PDP
is not required to honor the hint.
CtxtDialupIfFramedProtocolIpAddress CtxtDialupIfFramedProtocolIpAddress
This attribute indicates the address to be configured for This attribute indicates the address to be configured for
the user. It MAY be used in access response packets. It the user. It MAY be used in constructing policies for the
MAY be used in an access request packet as a hint by the NAS user.
to the PDP that it would prefer that address, but the PDP is
not required to honor the hint.
CtxtDialupIfFramedProtocolIpNetmask CtxtDialupIfFramedProtocolIpNetmask
This attribute indicates the IP netmask to be This attribute indicates the IP netmask to be
configured for the user when the user is a router to a configured for the user when the user is a router to a
network. It MAY be used in access response packets. It MAY network.
be used in an access request packet as a hint by the NAS to
the PDP that it would prefer that netmask, but the PDP is
not required to honor the hint.
4.8.3.2 CtxtDialupIfLoginService class 4.10.5 CtxtDialupIfLoginService class
The CtxtDialupIfLoginService class is an optional class that may be The CtxtDialupIfLoginService class is an optional class that may be
sent if a Login service is being provided. sent if a Login service is being provided. This class MAY be
specified in the ContextData PRC by the PDP in a decision message if
the PDP needs this context information (if it was not already setup
to be sent in the eventHandler). It MUST be sent up to the PDP in a
request message if it is specified via the ContextData PRC in an
eventHandler.
Weiss et al. Expires October 2000 [Page 38]
This class contains a single attribute: This class contains a single attribute:
CtxtDialupIfLoginIpHost CtxtDialupIfLoginIpHost
This attribute indicates the system with which to connect he This attribute indicates the system with which to connect he
user. It MAY be used in access response packets. It MAY be user.
used in an access request packet as a hint to the PDP that
the NAS would prefer to use that host, but the PDP is not
required to honor the hint.
4.8.3.3 CtxtDialupIfLoginLat class 4.10.6 CtxtDialupIfLoginLat class
This class MAY be specified in the ContextData PRC by the PDP in a
decision message if the PDP needs this context information (if it
was not already setup to be sent in the eventHandler). It MUST be
sent up to the PDP in a request message if it is specified via the
ContextData PRC in an eventHandler.
The CtxtDialupIfLoginLat class extends the The CtxtDialupIfLoginLat class extends the
CtxtDialupInterfaceLoginService class. Its attributes are: CtxtDialupInterfaceLoginService class. Its attributes are:
CtxtDialupIfLoginLatService CtxtDialupIfLoginLatService
This attribute indicates the system with which the user This attribute indicates the system with which the user
is to be connected by LAT. It MAY be used in access is to be connected by LAT.
response packets. It MAY be used in an access request
packet as a hint to the PDP, but the PDP is not required to
honor the hint.
CtxtDialupIfLoginLatNode CtxtDialupIfLoginLatNode
This attribute indicates the Node with which the user is to This attribute indicates the Node with which the user is to
be automatically connected by LAT. It MAY be used in access be automatically connected by LAT.
response packets. It MAY be used in an access Request
packet as a hint to the PDP, but the PDP is not required to
honor the hint.
CtxtDialupIfLoginLatGroup CtxtDialupIfLoginLatGroup
This attribute contains a string identifying the LAT group This attribute contains a string identifying the LAT group
codes which this user is authorized to use. It MAY be used codes which this user is authorized to use.
in access response packets. It MAY be used in an access
request packet as a hint to the PDP, but the PDP is not
required to honor the hint.
LAT supports 256 different group codes, which LAT uses as a LAT supports 256 different group codes, which LAT uses as a
form of access rights. LAT encodes the group codes as a 256 form of access rights. LAT encodes the group codes as a 256
bit bitmap. bit bitmap.
Administrators can assign one or more of the group code bits Administrators can assign one or more of the group code bits
at the LAT service provider; it will only accept LAT at the LAT service provider; it will only accept LAT
connections that have these group codes set in the bit map. connections that have these group codes set in the bit map.
The administrators assign a bitmap of authorized group codes The administrators assign a bitmap of authorized group codes
to each user; LAT gets these from the operating system, and to each user; LAT gets these from the operating system, and
uses these in its requests to the service providers. uses these in its requests to the service providers.
CtxtDialupIfLoginLatPort CtxtDialupIfLoginLatPort
This attribute indicates the Port with which the user is to This attribute indicates the Port with which the user is to
be connected by LAT. It MAY be used in access response be connected by LAT.
packets. It MAY be used in an access request packet as a
hint to the PDP, but the PDP is not required to honor the
hint.
Weiss et al. Expires October 2000 [Page 39] 4.11. AuthExt class
This is an abstract PRC. This PRC can be extended by authentication
PRCs that contain attributes specific to that authentication
protocol. An instance of the extended class is created by the PEP
and sent to the PDP. The PDP may send information back to the PEP or
may use the information to authenticate the PEP's Event Message.
This PRC itself should not be instantiated.
The data in this class is passed between the PDP and the client with
little or no involvement of the PEP except to forward it in the
appropriate AuthExt class instance. The PEP is not meant to store
AuthExt objects. As such, this class, along with all its extending
classes, is meant to be 'transient'. Its instances are temporary and
are deleted by the PEP after a certain time or event. The PDP, in
its decisions, must not refer to instances of this class that are
sent by the PEP in its requests. Likewise, the PEP must not refer to
instances sent by the PDP. Also, since instances are deleted, it is
possible for InstanceIds to be reused.
The AuthExt class is extended for each authentication mechanism
supported. As a base class, it is never instantiated.
The attributes of this class are:
AuthExtId (InstanceId)
identifies this object
4.11.1. UserAuthExt class
This is a concrete PRC used to contain user authentication fields.
This PRC extends the base PRC authExtEntry.
The attributes of this class are:
userAuthExtRealm (OCTET STRING)
The user realm octet string.
userAuthExtUsername (OCTET STRING)
The Username octet string.
4.11.2. AuthChapExt class
The AuthChapExt class extends the UserAuthExt class. It contains the
attributes of the CHAP protocol [CHAP]. (See section 3.3.)
The attributes that this class adds to the base class are:
AuthChapExtId (Unsigned32)
The AuthChapExtId is generated by the PEP. The ID value is
sent to the client. When the client endpoint (Peer)
generates a CHAP response it includes the same ID, and the
ID is then included in this attribute when it is sent to the
PDP.
AuthChapExtChal (Octet String)
The AuthChapExtChal is generated by the PEP. The Challenge
value is sent to the client, along with the ID. When the
client generates a CHAP response containing the ID and
Response (key), the Challenge associated with the ID is
included in this attribute when it is sent to the PDP.
AuthChapExtResp (Octet String)
The Response is calculated by the client and forwarded by
the PEP to the PDP.
4.11.3. AuthPapExt class
The AuthPapExt class extends the UserAuthExt class. It contains the
PAP Password. (See sec. 3.2.)
The attributes that this class adds to the base class are:
AuthPapExtPwd (Octet String)
A one-time password used to authenticate the client
4.11.4. AuthExtResult class
The AuthExtResult class extends the AuthExt class. It contains the
Authentication result Boolean flag.
The attributes that this class adds to the base class are:
AuthExtSuccessful (TruthValue)
A Boolean flag set to true if the authentication (via CHAP
or PAP) was successful.
4.11.5. AuthEapReqExt class
The AuthEapReqExt class extends the AuthExt class. It contains an
EAP message. (See sec. 3.1.) Instances of this class are sent by the
PDP to the PEP.
The attributes that this class adds to the base class are:
AuthEapReqExtSpecific (Octet String)
An EAP message [EAP] passed from the PDP to the client via
the PEP in a COPS-PR Decision message.
4.11.6. AuthEapRespExt class
The AuthEapRespExt class extends the AuthExt class. It contains an
EAP message. (See sec. 3.1.) Instances of this class are sent by the
PEP to the PDP.
The attributes that this class adds to the base class are:
AuthEapRespExtSpecific (Octet String)
An EAP message [EAP] passed from the client to the PDP via
the PEP in a COPS-PR Report message.
5. Message Types 5. Message Types
All PIB messages have some form of transactional semantics. Most all All PIB messages have some form of transactional semantics. Most all
transactions consist of requests and responses. Typical provisioning transactions consist of requests and responses. Typical provisioning
PIBs have the PDP requesting a provisioning decision to the PEP and PIBs have the PDP sending a provisioning decision to the PEP and the
the PEP responding with a success or fail. This PIB uses this PEP responding with a success or fail. This PIB uses this paradigm
paradigm in some cases, but it also uses a paradigm where the PEP in some cases, but it also uses a paradigm where the PEP initiates
initiates a request and the PDP responds with a success or fail. The an event and the PDP responds with a success or fail. The specific
specific use of this paradigm is with the PEP Access Request use of this paradigm is with the PEP Access Event Message, which is
message, which is triggered by a PEP event and requires a success or triggered by a PEP event and requires authentication success or
fail response. This section discusses both paradigms and how the failure semantics as part of the Provisioning Decision. This section
various classes defined in Section 4 are combined to form the discusses both paradigms and how the various classes defined in
various message interactions described in sections 2 and 3. Section 4 are combined to form the various message interactions
described in sections 2 and 3.
Each message description in this section will include the purpose of Each message description in this section will include the purpose of
the message, the COPS-PR message type, the direction of the message, the message, the COPS-PR message type, the direction of the message,
the class instances typically found in the message and the and the class instances typically found in the message.
request/response message it is peered with.
5.1. Accessor Provisioning Decisions 5.1. Event Handler Provisioning Decisions
The Accessor Provisioning Decision message is a COPS-PR Decision The Event Handler Provisioning Decision message is a COPS-PR
message used by the PDP to provision each Accessor in the PEP. It is Decision message used by the PDP to provision each Event Handler in
likely to be a piece of a larger Decision message that provisions the PEP. It is likely to be a piece of a larger Decision message
other data path components that occur either before or after the that provisions other data path components that occur either before
Accessor in the data path. However, it could also be sent as a part or after the Event Handler in the data path. However, it could also
of unrelated data path or other provisioning components. Accessor be sent as a part of unrelated data path or other provisioning
provisioning typically includes the Accessor class, and the components. Event Handler provisioning typically includes the
AccessorElement class, an optional set of AccessorContextData class EventHandler class, the EventHdlrElement class, the
instances, a optional set of AccessorAuthProtocol class instances, EventHdlrEventScope class, often the EventHdlrHandleScope class and
and an instance of the AccessorSessionScope class. the ContextData class. An optional set of EventHdlrAuthProtocol
class instances may be sent if a DataPathEventHandler is set up for
Access Event Messages.
Because the AccessorElement, AccessorContextData, Because the EventHdlrElement, ContextData, EventHdlrEventScope, and
AccessorAuthProtocol, and the AccessorSessionScope classes all the EventHdlrHandleScope classes all describe configuration details
describe configuration details of the Accessor, any of these class of the EventHandler, any of these class instances may be shared by
instances may be shared by multiple Accessor instances. Therefore, multiple EventHandler instances. Therefore, in many cases, an
in many cases, an Accessor Provisioning Decision will contain only EventHandler Provisioning Decision will contain only an EventHandler
an Accessor that references instances of the other classes defined that references instances of the other classes defined in previous
in previous Provisioning Decisions. In addition, these classes can Provisioning Decisions. In addition, these classes can also be
also be provisioned individually in anticipation of being applied to provisioned individually in anticipation of being applied to an
an Accessor. However, because there is a relationship between the EventHandler. However, because there is a relationship between the
classes, there is an order dependency between the classes. For EventHandler and EventHdlrElement classes, there is an order
instance, an AccessorSessionScope must be provisioned at the same dependency between the classes. For instance, an EventHdlrEventScope
time or before an AccessorElement making use of the must be provisioned at the same time or before an EventHdlrElement
AccessorSessionScope. AccessorElement, AccessorAuthProtocol, making use of the EventHdlrEventScope. EventHdlrElement,ContextData
AccessorContextData, and data path class instances referenced by an and data path class instances referenced by an EventHandler must be
Accessor must be provisioned at the same time or before the Accessor provisioned at the same time or before the EventHandler is
is provisioned. provisioned.
When the PEP receives an AccessorProvisioning Decision must always When the PEP receives an EventHandler Provisioning Decision, it must
respond with a Provisioning Report indicating success or failure. always respond with a Provisioning Report indicating success or
failure.
Weiss et al. Expires October 2000 [Page 40] Note that additional EventHdlrElements can simply be added to an
existing EventHandler by using the TagId (group identifier) for the
EventHandler to which the element is to be added. Additional
EventHdlrEventScope or EventHdlrHandleScope instances can be added
similarly by adding PRIs with the TagId value of the group these
instances are to be added to. This allows incremental updates to be
made to the Event Handlers.
5.2. Provisioning Report 5.2. Provisioning Decision
A report must follow all provisioning decisions described in section A report must follow all provisioning decisions described in section
5.1. This report may not have any class instances in it. However, it 5.1. This report may not have any class instances in it. However, it
explicitly notifies the PDP that the provisioning was successful or explicitly notifies the PDP that the provisioning was successful or
whether it failed. If many structures were simultaneously whether it failed. If many structures were simultaneously
provisioned in the Provisioning Decision and a failure occurred, provisioned in the Provisioning Decision and a failure occurred,
none of the class instances will be accepted by the PEP. Hence it is none of the class instances will be accepted by the PEP. Hence it is
possible to subsequent Provisioning Decisions to occur with a possible that subsequent Provisioning Decisions occur with a smaller
smaller subset of the class instances or an alternative set of class subset of the class instances or an alternative set of class
instances that can satisfy the service policies defined in the PDP. instances that can satisfy the service policies defined in the PDP.
5.3. PEP Access Request 5.3. PEP Event Message
A PEP Access Request is generated by the PEP to indicate that a new A PEP Event Message is generated by the PEP to indicate that a new
class of traffic has been identified by the Accessor and that a new class of traffic has been identified by the Event Handler. This
Session has been allocated. The PEP Access Request message uses a Event Message possibly uses a new COPS Request Handle. The decision
COPS-PR Request message. The PEP Access Request will always include to use a new COPS Request Handle or reuse an existing Handle is
an instance of the Session class. In order to support multiple PEP based on the EventHdlrHandleScope information configured in the
Access Request messages in a single COPS Request message, all class Event Handler. The Handle Scope information is a set of criteria
instances associated with the Session must immediately follow the that is protocol specific, and specifies the set of fields in the
Session class instance. Classes that may be part of a PEP Access protocol that the Event Handler is sensitive towards. The PEP Event
Request include one or more instances of Header and Interface data Message is essentially a COPS-PR Request message. The PEP Event
classes and no more than one instance of the AuthExt class. Message will always include an instance of the Event class. This
Event instance references which EventHandlerElement instance and
EventHandler instance caught the event. This tells the PDP what
events belong to which Event Handler. Other Classes that may be a
part of a PEP Event Message include one or more instances of
protocol specific Header Context Data and Interface data classes and
optionally an instance of one of the Authentication Extension
classes (for example, if the Event is an access event).
When authentication protocols such as PAP or CHAP are in use, the When authentication protocols such as PAP or CHAP are in use, the
PIB assumes that the UserId, Challenge, and Password will all be PIB assumes that the UserId, Challenge, and Password will all be
determined by the PEP prior to generating the PEP Access Request. determined by the PEP prior to generating the PEP Access Event
EAP is an exception to this rule because EAP assumes a direct Message. EAP is an exception to this rule because EAP assumes a
negotiation between the Endpoint and the Authentication server. For direct negotiation between the Endpoint and the Authentication
EAP, it is assumed that the Endpoint generates a response to the EAP server. For EAP, it is assumed that the Endpoint generates a
Identity Request message before the PEP sends the Access Request. response to the EAP Identity Request message before the PEP sends
This allows the PEP to fill in the Username and Realm in the Session the Access Event Message. This allows the PEP to fill in the
table. However, for this scenario, it is also assumed that the PEP Username and Realm in the UserAuthExt table. However, for this
Access Request will include the EAP Identity Response in the scenario, it is also assumed that the PEP Access Event Message will
authEapRespExtSpecific attribute of the AuthEapRespExtEntry class. include the EAP Identity Response in the authEapRespExtSpecific
Subsequent EAP negotiation prior to the final PDP Access Response attribute of the AuthEapRespExtEntry class. Subsequent EAP
message will be performed with the Opaque Decision and Opaque Report negotiation will be performed with the Opaque Decision and Opaque
message types. Report message types. When the negotiation is complete the PDP send
a Provisioning Decision message (that includes an instance of the
5.4. PDP Access Response AuthExtResult class specifying success or failure). Note that all
interactions resulting from a given Event Message (including
authentication negotiation) is performed within the context of a
single COPS Request Handle. The COPS Request Handle provides an
independent dialog between the PDP and the PEP to fully process an
Access Event Message in a synchronous way.
When the PDP has all the necessary information to determine whether 5.4. PDP Provisioning Decision
the session is authorized or not and it has completed any
intermediate data path PRIs that the session may be dependent on,
the PDP will generate a PDP Access Response message. The PDP Access
Response message only contains the instance of the Session table
passed in the PEP Access Request. The PDP is capable of modifying
two attributes in the Session table PRI. One attribute is the
sessionStatus, which the PDP MUST modify to indicate whether the
Session is authorized or not. The second attribute is the
sessionDataPath, which the PDP may modify to indicate what specific
Weiss et al. Expires October 2000 [Page 41] When the PDP has all the necessary information to determine what
packet processing should occur for all traffic matching the session policies to provision for the event that was generated by the PEP,
criteria. and it has completed any intermediate data path provisioning that
the event may be dependent on, the PDP will generate a PDP
Provisioning Decision message. The PDP Provisioning Decision message
only contains the instances of the classes the PDP wants to
configure as a result of the event. In addition to this message the
PDP may also send unsolicited Provisioning responses on other COPS
handles to add policies that may be shared across events.
The PEP is the only entity that knows when traffic is no longer The PEP is the only entity that knows when traffic is no longer
flowing through a particular session (either because of a timer flowing through a particular session (either because of a timer
expiring or because of a physical link termination). Therefore expiring or because of a physical link termination). Therefore
lifetime of a Session table instance are always controlled by the lifetime of a COPS Request handle is always controlled by the PEP.
PEP. The PDP may advise the PEP that the session is no longer valid. The PDP may advise the PEP that the Handle is no longer valid via a
However, the ultimate dispensation of the Session table and the provisioning update. However, the ultimate dispensation of the
related tables are always determined by the PEP. The PDP can Request Handle and the associated tables are always determined by
indicate that a Session may no longer have access to resources the PEP. The PDP can also indicate that a traffic flow may no longer
either by changing the sessionStatus attribute to ˘Disabled÷ or by have access to resources by changing the data path to drop packets
modifying the sessionDataPath to drop packets arriving for that arriving for that traffic flow. Since the PDP can modify the data
session. Since setting the sessionStatus to ˘Disabled÷ will result path such that all packets for the flow will be dropped, both
in all packets for the session being dropped, both alternatives alternatives achieve the same semantics. The PEP can delete the COPS
achieve the same semantics. The PEP can ˘Disable÷ the session simply Request Handle simply by notifying the PDP via a Delete Request
by notifying the PDP that the Session instance is no longer valid. Message that the provisioned policies for that Handle are no longer
Since a COPS-PR Provisioning Decision is used send the PDP Access valid. Since a COPS-PR Provisioning Decision is used, the PEP must
Response, the PEP must send a report back to the PDP to confirm that send a report back to the PDP to confirm that there are no problems
the Session is still valid and that there are no problems with the with the data path change requested by the PDP.
SessionDataPath change requested by the PDP.
When a Session is removed all relating class instances may be
removed as well. Typically these will include header and
authentication table instances. Interface table instances may
continue to be valid if multiple Sessions are sharing the same
interface description.
5.5. Session-specific ContextData Request When a COPS Request Handle is removed all contained class instances
must be removed as well. Typically these will include header and
authentication table instances.
The AccessorContextData class can be used either during the 5.5. PDP fetching Event-specific ContextData
configuration of the Accessor to specify what context data should be
sent with each PEP Access Request or it can be used by the PDP to
get additional context data for a session after it receives an
Access Request for that session. In the latter case, the PDP may
send a Session-specific ContextData Request to retrieve the specific
information needed to either authorize a pending session or monitor
an active session. Since each ContextData class only retrieves a
specific subset of the information regarding a session, a single
request message can contain multiple instances of the ContextData
class, thereby supporting the retrieval of as much session-specific
information as needed in a single message.
The COPS-PR message type used for a Session-specific ContextData The ContextData class can be specified either during the
Request is a Provisioning Decision message. Further, when the configuration of the EventHandler to indicate what context data
ContextData class is sent in a Session-specific ContextData Request, should be sent with each PEP Event Message or it can be used by the
the RefId attribute must contain a valid InstanceId for in the PDP to get additional context data for an event after it receives a
Session table (described in section 4.6). It does not matter what Event Message. In the latter case, the PDP may send a solicited
the current state of the Session table entry is. Since the TagId is response that specifies ContextData for the last Event Message
only used when the ContextData class is configured with an Accessor, received on the same Request Handle. The ContextData message
the TagId attribute should not be set when the class is used in a contains PRC names to retrieve the specific information needed to
Session-specific ContextData Request. When the PEP receives a either authorize a pending event, monitor a set of policies bound to
the handle or get more context information regarding the event.
Since each ContextData class only retrieves a specific subset of the
information regarding the event within the context of a Request
Handle, a single request message can contain multiple instances of
the ContextData class, thereby supporting the retrieval of as much
event-specific information as needed in a single message.
Weiss et al. Expires October 2000 [Page 42] The COPS-PR message type used to fetch Event-specific ContextData is
Session-specific ContextData Request, it will send a Session- a Provisioning Decision message. The ContextData class instances are
specific ContextData Response message back to the PDP. sent in an updated Event-specific ContextData Request on the same
COPS Request Handle. Since the TagId in the ContextData class is
only used when the ContextData class is configured with an
EventHandler, the TagId attribute should not be set when the class
is used in an Event-specific ContextData Fetch. When the PEP
receives a message from the PDP asking for Event-specific
ContextData, it will send an Event-specific ContextData message in a
COPS Request message back to the PDP.
Session-specific ContextData Response will contain a set of Header The updated Event-specific ContextData Request from the PEP will
and Interface data class instances. However, because these instances contain a set of Header and Interface context data class instances.
do not contain a Reference Id to the Session, we must rely on the Since the updated request uses the same Request Handle the PDP knows
COPS protocol to bind the request with the response. This precludes which event is being updated by more context data. Using PDP Fetched
PDP from generating multiple Session-specific ContextData requests ContextData messages precludes the PDP from provisioning the PEP to
for different sessions in the same Decision message. allow multiple simultaneous Event Messages outstanding on the same
Handle.
5.6. Session-specific ContextData Response 5.6. Event-specific ContextData Response
The Session-specific ContextData Response message is used to report The Event-specific ContextData Response message is used to report
specific interface and/or packet header information back to the PDP. specific interface and/or packet header information back to the PDP.
This message is implemented as a COPS-PR Report message. A Report This message is implemented as a COPS-PR Report message. A Report
message may include any number of Interface or Header table message may include any number of Interface or Header table
instances. However, because Reference Identifiers to the Session instances. However, because Reference Identifiers to the Event table
table are not specified in the header or interface data tables, a are not specified in the header or interface data tables, a Report
Report message may contain header and interface data for one and message may contain header and interface data for one and only one
only one Session. Event or the most recent Event Message received on that specific
COPS Request Handle.
5.7. Opaque Decision 5.7. Opaque Decision
An Opaque Decision message is used to send specialized An Opaque Decision message is used to send specialized
authentication messages from the PDP to the PEP. Specifically, this authentication messages from the PDP to the PEP. Specifically, this
type of COPS-PR Decision message is used to pass EAP request type of COPS-PR Decision message is used to pass EAP request
messages. The class used in this message is used to send messages. The class used in this message is used to send
authEapReqExt table instances. authEapReqExt table instances.
5.8. Opaque Report 5.8. Opaque Report
skipping to change at line 2164 skipping to change at page 44, line 4
5.7. Opaque Decision 5.7. Opaque Decision
An Opaque Decision message is used to send specialized An Opaque Decision message is used to send specialized
authentication messages from the PDP to the PEP. Specifically, this authentication messages from the PDP to the PEP. Specifically, this
type of COPS-PR Decision message is used to pass EAP request type of COPS-PR Decision message is used to pass EAP request
messages. The class used in this message is used to send messages. The class used in this message is used to send
authEapReqExt table instances. authEapReqExt table instances.
5.8. Opaque Report 5.8. Opaque Report
An Opaque Report message is used to send specialized authentication An Opaque Report message is used to send specialized authentication
messages from the PEP to the PDP. Specifically, this type of COPS-PR messages from the PEP to the PDP. Specifically, this type of COPS-PR
Report message is used to pass EAP response messages. The class used Report message is used to pass EAP response messages. The class used
in this message is used to send authEapRespExt table instances. in this message is used to send authEapRespExt table instances.
6. Combining Data Structures in Messages 6. Combining Data Structures in Messages
In the most degenerate case, the PDP provisions the Accessor with no In the most degenerate case, the PDP provisions the EventHandler to
ContextData. In this case, the PEP will generate an Access Request only send the Event object when an event occurs. The PDP then
message. The PDP will then perform a series of Session-specific requests Event-specific Context Data that the PEP will respond to
ContextData Requests. In addition, if EAP authentication is with Report Message. In addition, if EAP authentication is required,
required, a sequence of Opaque Decisions and Opaque Reports are also a sequence of Opaque Decisions and Opaque Reports are also required.
required. Finally, if new data paths need to be provisioned Finally, if new data paths need to be provisioned (including
(including specialized Accessors), normal Provisioning Decision and specialized EventHandlers), normal Provisioning Decision and Report
Report messages must also be exchanged. messages must also be exchanged. Note that these provisioning
decisions may be on separate COPS Request Handles.
In some environments, it is essential to complete the authorization In some environments, for example authorization, it is essential to
process as quickly as possible. The way to accelerate this process complete the transaction as quickly as possible. The way to
is to combine as many messages into a single message as possible. accelerate this process is to combine as many messages into a single
This section describes which messages can be collapsed, and what the message as possible. This section describes which messages can be
rules are for collapsing the messages. collapsed, and what the rules are for collapsing the messages.
Weiss et al. Expires October 2000 [Page 43] 6.1. Combining Context Data in Event Messages
6.1. Combining Access Request and Session-specific ContextData messages Previous sections have discussed at length how Event Handlers can be
pre-provisioned to generate specific Event Messages with ContextData
(Interface and Header data) in the PEP Event Message. When the
choice of what context data is entirely dependent on information
found in the PEP when a packet causing the Event Message, pre-
provisioned Event Handlers is the preferred approach.
Previous sections have discussed at length how Accessors can be pre- 7. Access Bind Usage Examples
provisioned to generate specific ContextData (Interface and Header
data) with the PEP Access Request. When the choice of what context
data is not dependent on the specific semantics of each session,
pre-provisioned Accessors is the preferred approach.
6.2. Combining Access Response and Provisioning Decision messages Following examples on how the Access Bind PIB PRCs are used provide
some additional clarifications on the PRC definitions. But they by
no means indicate all the PRCs needed for the application given by
the example. And providing these examples here does not indicate
where the application specific PRCs should be defined. These
examples are provided only to assist better and easier understanding
of the Access Bind PIB.
What has not been discussed in any detail is how Provisioning 7.1 Wireless LAN (802.11 Access Point) Usage Example
Decisions can be pre-pended to PDP Access Response messages. In
general the preferred approach is to pre-provision as much of the
data path as possible. However, when this is not possible, the PDP
Access Response message can be combined with the data path
Provisioning Decisions that the Session table entry (actually, the
sessionDataPath attribute) in the PDP Access Response is dependent
on. When this occurs, it is important to note that all Provisioning
Decisions must report back to the PDP whether the Decision was
successfully installed.
Since both the PDP Access Response message and the Provisioning A wireless LAN Access Point (AP) is pictured in Figure 7.1 below.
Decision are in the same message (a Decision message), COPS-PR This is based roughly on 802.11/802.1x concepts. The following is
transactional semantics apply to the entire combined message. meant to give an indication of how the Access Bind PIB could be
Therefore, if the Decision fails, the Session will remain in the included in such an AP. Note that this is an exercise to see if the
˘Pending÷ state with the sessionDataPath attribute unaltered. Given concepts fit together, not a proposal for exactly how they would
that the sessionDataPath would probably be invalid if the fit.
Provisioning Decision failed, this is the appropriate behavior.
7. The AccessBind PIB Module The AP shown below includes a ŠService ManagerĂ (SM), which
interfaces with the wireless data interface. For incoming wireless
data it separates management frames and level 2 frames. In the
following we will deal particularly with Associate and ReAssociate
Management Frames.
The SM (as interpreted here) takes Associate and Reassociate
management frames and creates a temporary Port Access Entity PAE for
the association. The PAE must then be authenticated and provisioned
by an external Authentication Server (AS). Communication with the
AS is assumed in this model to be mediated by a Policy Enforcement
Point (PEP, which is part of the AP). The AS acts as a Policy
Decision Point (PDP).
oooooooooo Ethernet Port
o
+--------o-------------------------------------+
| o Service Manager |
| o +-----+ | (1) +------+
| +------o------+ | PEP | |Capabilities| |
| |QoS policies | | +--+----------->| Auth |
| | for | | | | |Server|
| | previously | | | | (2) |(PDP) |
| |authenticated| | | |Service Mgr | |
| | PAEs | | | |Provisioning| |
| | o |<-+---------+--------+-----+--+------------+ |
| +------o------+ | | | | | | |
| o ^ | V | | | | |
| o | | +-------------+ | | | (3) | |
| o | | |Authenticator| | | | Event Msg | |
| o | | | (Event +--+-----+--+----------->| |
| o | | | Handler) | | | | | |
| o | | | | | | | (4) | |
| o | | | | | | |EAP exchange| |
| o | | | |<-+-----+--+------------+ |
| o | | | |--+-----+--+----------->| |
| o | | +-----o-------+ | | | | |
| o | | o | | | (5) | |
| o | | o | | | Decision | |
| o +-----------------------+-----+--+------------+ |
| o | | o | | | | |
| o V V o | | | (6) | |
| +---o-----------------o---+ | | |Success Rpt | |
| | o Classifier o | | +--+----------->| |
| | o o | +-----+ | +------+
| |Controlled Uncontrolled| |
| | Port Port | |
| | ooooo ooooo | |
| | ooooo ooooo | |
| +------------o------------+ |
| o |
+-----------------o----------------------------+
o
ooooooooooooooooooooo
o o
+-------o--------+ +-------o--------+
|Wireless Station| |Wireless Station|
+----------------+ +----------------+
Figure 7.1: Wireless LAN AP Architecture
7.1.1 Wireless LAN Access Event Handler Provisioning
In an Access Bind PIB implementation, figure 7.1 shows the SM
sending a REQ at boot time to tell the AS that it is up and what
capabilities it has. The PDP returns a configuration to support the
SM. In particular, this configuration includes provisioning
information for how to instantiate a PAE and what trigger
information should be sent by the instantiated PAE to the PDP.
The provisioning of the Event Handler is supported by the Access
Bind PIB by using the following PRCs in the decision (DEC) message:
- eventHandler
- eventhdlrElement
- eventhdlrEventScope
With eventhdlrEventScopeFilter indicating how the signaling protocol
is recognized.
7.1.2 Wireless LAN Access Event Handling
When an event (here a Associate or ReAssociate) is detected the
SM/event handler instantiates and initializes a PAE. The initial
PAE instance includes an access port which splits internally into a
controlled and uncontrolled port.
The controlled port is what is used to pass data from the access
port to the external Ethernet. It is controlled in that there is a
switch that must be turned on by the authenticator before data can
flow. It may also have QoS parameters that can be controlled by the
AS. In its initial state the controlled port drops all incoming
frames.
The uncontrolled port connects to an internal authenticator. The
authenticator creates the initial trigger. In some cases it may
need to send an EAP frame back to the Station prior to sending the
initial trigger, and other times it may have enough information from
the initial Associate or ReAssociate to create the trigger
immediately.
The Event handling is supported by the Access Bind PIB.
The PEP creates an instance of event PRC, with eventEventhdlr
referencing the eventHandler, and eventCause referencing
eventhdlrElement provisioned in Access Event Handler Provisioning
above.
This event PRI will be sent by the PEP to the PDP in a REQ using a
new COPS Request Handle. This REQ message may contain additional
PRIs as dictated by how a specific signaling protocol should be
handled.
7.1.3 Wireless LAN Access Event Decision
The AS/PDP decides whether the trigger contains enough information
to make an authentication decision. If not, it may initiate an EAP
dialog through the authenticator to the STATION.
Once it has enough information the PDP makes a decision and sends a
Provisioning message to the AP that sets QoS parameters and ŠclosesĂ
the switch on the controlled port. Since the controlled and
uncontrolled port is easily modeled with a DiffServ Classifier, the
closing of the switch is simply a matter of a installing a Decision
in the classifier indicating that subsequent traffic matching the
specific PAEĂs criteria should be bound to the set of pre-existing
policies that are appropriate for that authenticated PAE.
The decision (DEC) message sent by the PDP to the PEP will be using
the same COPS Request Handle created as a result of the first in
Access Event. The content (PRCs) carried by the DEC message will
depend on the functionality need to be provided. It may be command
to ŠcloseĂ the switch on the controlled port, it may contain QoS
parameters.
7.2 RSVP Usage Example
RSVP is a signaling protocol used for a variety of purposes
including some call setup applications and MPLS label distribution
for traffic engineering. RSVP uses a number of message types to
negotiate both the hop-by-hop path and the service requirements
between a sender and one or more receivers.
Some RSVP messages contain information that helps determine whether
the reservation should be accepted or not. However, the router may
not equipped with sufficient context to take advantage of the
information in determining whether to accept or reject an RSVP
message. COPS was designed to pass specific RSVP messages to a PDP
(Policy Server). The PDP could then analyze the RSVP message and
usually determine whether to accept or reject the reservation.
With the advent of COPS-PR, it became possible to construct more
sophisticated policies beyond simple accept or reject messages.
However, these more sophisticated policies were targeted for
DiffServ rather than RSVP. With the definition of the AccessBind
PIB, it becomes possible to provision a router not only to specify
which RSVP messages should be sent to the PDP, but also to use
existing PIBs to specify how the QoS requirements in a RSVP
reservation should be supported in a specific router implementation.
Two types RSVP specific structures are added to AccessBind to
support RSVP. In order to provision the EventHandler class to detect
RSVP messages, a number of filter classes must be defined. These
filter classes are general purpose and could be used both by
EventHandlers and by Classifiers although the semantics of the
filter class are somewhat different for each. The other group of
classes is the Context Data classes that pass some or all parts of
the RSVP message to the PDP when the EventHandler generates an
event.
Because COPS assumes that all RSVP message objects are sent to the
PDP, each well known RSVP object will be assigned a unique Context
Data PRC identifier and the rest of the RSVP objectĂs attributes
will be part of the PIB class in the same order and format as in the
original RSVP object. The actual PRC mappings for these objects can
be found in the PIB definition. For details on the operation of
these objects refer to [RSVP] and [INTSERV]. In addition, a PIB
class is also defined to support unrecognized RSVP objects.
A Context Data PIB class is also specified to describe the relevant
RSVP common header attributes. The attributes in the common header
that will be specified are:
1. The RSVP MsgType attribute, which distinguishes a PATH message
from a RESV or PATHerr message.
2. The RSVP Flags attribute is used to indicate whether Refresh
Reduction is possible or not.
3. The Send TTL (Time To Live) attribute, provides a easy
mechanism for determining whether non-RSVP hops have been
traversed by comparing this field with the IP TTL field.
4. The In Interface (if known)
5. The Out Interface (if known)
A special context data class, called AllRSVPMsgObjects, is defined
to simplify the process of specifying the set of RSVP objects to be
included with a COPS-PR Event message. Rather than explicitly
specifying every context data class that should be included with the
Event message, this class (when referenced by PRC through the
ContextDataIfElement attribute of the ContextData class) indicates
that all RSVP objects, including the common header class described
above, should be encapsulated and propagated to the PDP. All Refresh
Reduction related RSVP objects (MESSAGE_ID, MESSAGE_ID_ACK, and
MESSAGE_ID_NACK) are explicitly excluded from being sent to the PDP
when the AllRSVPMessageObjects attribute is set to True. These
objects are specifically for purpose of synchronizing state between
RSVP hops and bears no value in the policy decision process.
However, a context data PIB object is defined for each of these
classes in the event that a PDP determines that it needs these
objects.
The EventScope classes have been specified to roughly follow the
same mappings as the Context Data PIB classes. However, since the
typical criteria for outsourcing a RSVP message are usually rather
simple, only a subset of the RSVP objects require mappings to COPS-
PR filter classes. If some implementations require support for
filtering additional objects, it is trivial to extend the filters.
Note that the filters bound to EventHandlers determine whether a
matching packet should generate an Event or not.
The RSVP objects that will be mapped to filters in this
specification will include the RSVP common header, the RSVP Dclass
object, the RSVP session object, and the RSVP style object. The last
three are used to describe various characteristics of the data
traffic for which the reservation is being performed. Since the
filters can describe both AND and OR semantics, the challenge is in
organizing the fields of the objects to simplify filter expressions
as much as possible. Since this is the primary goal the appropriate
attributes of each object have been combined into a single PIB
class. The RSVP filter PIB class contains the following attributes.
The fields marked with asterisks will be represented as masked
values (for IP addresses) and ranges (for UDP/TCP ports) to add
flexibility.
RSVP MsgType
RSVP Flags
Send TTL
DCLASS DSCP
Session Dest IP*
Session Protocol
Session Dest Port*
Filter Src IP*
Filter Src Port*
Style value
This paper does not address reservation specification (TSPEC and
FLOWSPEC) modifications that depend on the RSVP refresh model. RSVP
refresh reduction [REFRESH] is assumed as a simplifying assumption
for this application of the Access Bind PIB. However, if support for
traditional RSVP refresh is desirable, it can be supported in this
model by adding explicit filters for the RSVP FlowSpec and RSVP
Tspec objects as specified in [IntServ].
In order to support RSVP outsourcing with the AccessBind PIB the
Event Handler must be provisioned with the appropriate settings to
recognize specific RSVP messages, create new request handles, and
generate events (outsourcing requests). After we have described how
this is accomplished, we will show the actual message flows involved
in the RSVP outsourcing process.
The specific PIB classes that need to be provisioned are the
EventHandler, EventhdlrElemenet, ContextData, EventhdlrHandleScope,
and EventhdlrEventScope. The EventHandler provides a termination
point for processing RSVP messages. As RSVP messages arrive, they
are directed to the EventHandler by a classifier. In this scenario
the EventHandler as behaving as a termination point for all RSVP
messages. Hence, the EventHandler class is provisioned with no data
path elements following the EventHandler. Therefore, the attribute
eventhdlrNonMatchNext is left unassigned.
Alternatively, the EventHandler can also be provisioned such that
RSVP and non-RSVP packets alike pass through the EventHandler, but
only RSVP messages invoke events. In this case, the attribute
eventhdlrNonMatchNext would specify the next data path element that
should process any packets not matching the EventHandlerĂs criteria
(non RSVP packets).
The EventhdlrElement class identifies a specific category of events.
Suppose one wanted to generate different Events for PATH messages
and RESV messages. This could be done by configuring one
EventhdlrElement to only match PATH messages and another
EventhdlrElement to only match RESV messages. Event messages contain
a reference to the EventhdlrElement that generated the event.
Therefore, it is possible to generate different events from the same
EventHandler.
The EventhdlrElement contains two main semantics. First, it
specifies the criteria for creating new Request Handles. Each
Request Handle constitutes a unique dialog between the PEP and PDP.
The second semantic is the criteria for generating events. In some
situations, it is desirable to generate a one-time event and not
generate events when similar messages are seen later. A good example
of this is RSVP Refresh messages. When RSVP Refresh messages are
used to indicate that the reservation is still active, generating
events for each message is inappropriate. In contrast, when Refresh
Reduction [Refresh] is active, only reservation changes are
propagated as full RSVP messages. In this situation, every message
may constitute an Event.
With RSVP it is usually appropriate to assign a unique COPS-PR
Request Handle for every new RSVP session. Since EventHandlers are
typically bound to an interface data path, the RSVP Path message and
the Resv message will be processed on different data paths.
Therefore, unique events and unique COPS-PR Request Handles will
typically be assigned for each message type. However, this is not
significant since the provisioning objectives for Path messages are
different from the provisioning objectives for Resv messages. For
RSVP, the EventhdlrElement will use the Tag Reference
EventhdlrElementHandleScope to describe the criteria for creating a
unique handle. Each EventhdlrHandleScope object will contain
pointers to the RSVP filter objects mentioned earlier to describe
the various fields whose combination of values constitute a unique
handle.
Typically, the Filter class used is the RSVP filter class. For this
class, the session attributes (SessionDestIP, SessionDestPort, and
SessionProtocol) will be assigned wildcard values and all other
attributes assigned to NULL to indicate that any combination of
these attributes constitutes a unique handle. When various messages
arrive that require the generation of an event and that have a newly
unique combination of the filter attribute values, a new request
handle will be assigned. When a message arrives for which a previous
message has already generated a handle, that handle is used to pass
the appropriate event to the PDP.
The other class pointed to by the EventhdlrElement is the
EventhdlrEventScope. This class describes the criteria for
generating an event. Typically, the MsgType attribute in conjunction
with the session attributes will be wildcarded and the other fields
assigned to NULL to indicate that all RSVP messages should be sent
to the PDP. This describes the criteria for an event: Every time a
unique combination of all these attributes occurs, generate a new
event.
In many cases it may make sense to assign the filter attributes
(SessionDestIP and SessionDestPort) to the EventhdlrEventScope
and/or EventhdlrHandleScope class. This would be done when it is
desirable to notify of the PDP of the need to allocate additional
resources to a set of reserved flows going to the same destination
but originating from different sources.
A new COPS-PR Request Handle MUST only be created when a valid event
occurs. If a packet matches the criteria described by
EventhdlrHandleScope but does not match any EventhdlrEventScope
criteria, a COPS-PR Request Handle must not be generated.
This version of the paper only describes how RSVP can be supported
when Refresh Reduction [REFRESH] is being used. The complexity of
addressing the distinction between RSVP refresh messages and
reservation update messages is too great to be addressed in this
version. Any RSVP message containing bundle messages (MsgType 12)
MUST be decomposed and each message in the bundle must be
iteratively processed through the EventHandler as if individual RSVP
messages were generated from the RSVP neighbor. Whether
EventhdlrMatchNext applies to the individual sub-messages or the
bundled message is beyond the scope of this paper.
Irrespective of whether Refresh Reduction is in use or not, the RSVP
daemon is responsible for aging out reservations that are no longer
valid. As with traditional COPS, when a reservation is aged out, the
RSVP daemon or other entity responsible for aging out reservations
MUST take responsibility for deleting COPS Request Handles. This
allows the PDP to clean up state associated with the reservation and
ensures the proper removal of any policies in the PEP specifically
assigned through the COPS Request Handle.
Figure 7.2 shows how the various Event Handler objects would be
provisioned in a router to ensure that an event is generated for
every RSVP message.
+-------------------+
|EventHandler |
| Id=EH1 |
| NonMatchNext=<NUL>|
| ElementRef=(Elem1)|
+-------------+-----+
|
V
+------------------+ +-----------------+
|EH_Element | |ContextData |
| Id=Elem1 | | Id=CD1 |
| MatchNext=<NUL> | | DataGroup=RSVP |
| Criteria=AllMatch| | IfElement=(PRC)-+--AllRSVPMsgObjects
| Context=(RSVP)---+--->| DataEncap=0 |
| EventScope=(MSG)-+--+ +-----------------+
| HandleScope=(HD) | |
+-------------+----+ +-------------------+
| | |
| | +-------------+ | +-------------+
| +->|EventScope | +-->|EventScope |
| | Id=Ev1 | | Id=Ev2 |
| | Group=MSG | | Group=MSG |
| | Filter=(F1)-+--+ | Filter=(R1)-+--+
| | Precedence=1| | | Precedence=1| |
| | ChangeFlag=?| | | ChangeFlag=?| |
| +-------------+ | +-------------+ |
| | |
| +-------------+ V V
| |HandleScope | +-------------+ +------------+
+->| Id=Hd1 | +->|IpFilter | |RsvpFilter |
| | Group=HD | | | Id=F1 | | Id=R1 |
| | Filter=(F1)-+--+ | Protocol=46 | | DestIP=* |
| | Precedence=1| +-------------+ | Protocol=* |
| +-------------+ | DestPort=* |
| +------------+ | SrcIP=* |
| +-------------+ +->|RsvpFilter | | SrcPort=*
| |HandleScope | | | Id=R2 | +------------+
+->| Id=Hd2 | | | DestIP=* |
| Group=HD | | | Protocol=* |
| Filter=(R2)-+--+ | DestPort=* |
| Precedence=1| +------------+
+-------------+
Fig 7.2: Representation of an Event Handler for RSVP
Figure 7.2 represents the set of PIB classes that would be
provisioned in order to indicate to the PEP that RSVP messages
should generate unique events for any combination of filters or
sessions. However, all messages using the same unique session will
share the same COPS Request Handle.
When an RSVP message arrives at the PEP with an new combination of
session attribute values, the PEP will create a new COPS Request
Handle. Following this, an Event message will be generated
containing an Event object with references to EventHandler EH1 and
EventhdlrElement Elem1. These two pieces of information allow the
PDP to determine which provisioned EventHandler and which specific
event type generated the event. In addition the Event message also
contains a set of Context Data objects. Since the AllRSVPMsgObjects
class was specified in the ContextData class, all RSVP objects are
encapsulated in COPS-PR PIB classes and sent to the PDP in the Event
message.
When the PDP receives the Event message, it determines what policies
to provision in the PEP. Suppose the RSVP message was a reservation
request for a controlled load service with a bandwidth allocation of
1 Mbps and session object contained (SessionDestIP = 1.2.3.4,
SessionProtocol=UDP, SessionDestPort=7788). If the routerĂs
implementation only supported 4 queues with respective bandwidth
allocations of 20Mb, 40Mb, 30Mb, and 10Mb, the PDP may decide that
allocating the reservation to queue 3 can satisfy the reservation
request. Hence, a PDP might generate a provisioning policy as a
result of the PEPĂs Event message that creates a new Classifier
Element and Filter that matches all 1.2.3.4:7788 traffic and directs
it to queue 3.
8. The AccessBind PIB Module
ACCESSBIND-PIB PIB-DEFINITIONS ::= BEGIN ACCESSBIND-PIB PIB-DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
Unsigned32, Integer32, MODULE-IDENTITY, Unsigned32, Integer32, MODULE-IDENTITY,
MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib
FROM COPS-PR-SPPI FROM COPS-PR-SPPI
InstanceId, Prid InstanceId, Prid
FROM COPS-PR-SPPI-TC FROM COPS-PR-SPPI-TC
RoleCombination, PrcIdentifier RoleCombination, PrcIdentifier
FROM FRAMEWORK-ROLE-PIB FROM FRAMEWORK-TC-PIB
InetAddress, InetAddressType InetAddress, InetAddressType
FROM INET-ADDRESS-MIB FROM INET-ADDRESS-MIB
TruthValue, PhysAddress TruthValue, PhysAddress
FROM SNMPv2-TC; FROM SNMPv2-TC;
accessBindPib MODULE-IDENTITY accessBindPib MODULE-IDENTITY
SUBJECT-CATEGORIES { all } SUBJECT-CATEGORIES { all }
LAST-UPDATED "200107101600Z" LAST-UPDATED "200202202002Z"
ORGANIZATION "IETF RAP WG" ORGANIZATION "IETF RAP WG"
CONTACT-INFO " CONTACT-INFO "
Weiss et al. Expires October 2000 [Page 44]
Walter Weiss Walter Weiss
Ellacoya Networks Ellacoya Networks
7 Henry Clay Drive 7 Henry Clay Drive
Merrimack, NH 03054 Merrimack, NH 03054
Phone: 603-879-7364 Phone: 603-879-7364
E-mail: wweiss@ellacoya.com E-mail: wweiss@ellacoya.com
" "
DESCRIPTION DESCRIPTION
"A PIB module containing the set of classes to bind "A PIB module containing the set of classes to
authorization and authentication to COPS configure generic event handlers, and outsource
Provisioning " events as they occur. One application of this PIB is
to bind authorization and authentication to COPS
Provisioning."
::= { pib xxx } -- xxx to be assigned by IANA ::= { pib xxx } -- xxx to be assigned by IANA
-- --
-- The branch OIDs in the AccessBind PIB -- The branch OIDs in the AccessBind PIB
-- --
capabilityClasses OBJECT IDENTIFIER ::= { accessBindPib 1 } capabilityClasses OBJECT IDENTIFIER ::= { accessBindPib 1 }
sessionClasses OBJECT IDENTIFIER ::= { accessBindPib 2 } eventClasses OBJECT IDENTIFIER ::= { accessBindPib 2 }
accessorClasses OBJECT IDENTIFIER ::= { accessBindPib 3 } eventHdlrClasses OBJECT IDENTIFIER ::= { accessBindPib 3 }
contextClasses OBJECT IDENTIFIER ::= { accessBindPib 4 } contextClasses OBJECT IDENTIFIER ::= { accessBindPib 4 }
authClasses OBJECT IDENTIFIER ::= { accessBindPib 5 } authClasses OBJECT IDENTIFIER ::= { accessBindPib 5 }
filterClasses OBJECT IDENTIFIER ::= { accessBindPib 6 }
-- --
-- Session Table -- Event Table
-- --
-- Instances of this table represent events that occurred at
-- the PEP. The events reference the event handler instance
-- and the specific event handler element that the event was
-- caught by.
sessionTable OBJECT-TYPE eventTable OBJECT-TYPE
SYNTAX SEQUENCE OF SessionEntry SYNTAX SEQUENCE OF EventEntry
PIB-ACCESS install-notify PIB-ACCESS notify
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class is created by the PEP and sent "An instance of this class is created by the PEP and sent
to the PDP. The PDP will fill in the sessionStatus field to the PDP. As a result of this event, The PDP may send
and send the instance back when sending a decision." additional unsolicited decisions to the PEP after
sending the mandatory solicited decision for the event."
::= { sessionClasses 1 } ::= { eventClasses 1 }
sessionEntry OBJECT-TYPE eventEntry OBJECT-TYPE
SYNTAX SessionEntry SYNTAX EventEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of the sessionTable PRC." "An instance of the eventTable PRC."
PIB-INDEX { sessionId } PIB-INDEX { eventId }
UNIQUENESS { } UNIQUENESS { }
::= { sessionTable 1 } ::= { eventTable 1 }
SessionEntry ::= SEQUENCE {
Weiss et al. Expires October 2000 [Page 45] EventEntry ::= SEQUENCE {
sessionId InstanceId, eventId InstanceId,
sessionStatus INTEGER, eventEventHdlr ReferenceId,
sessionRealm OCTET STRING, eventCause ReferenceId
sessionUsername OCTET STRING,
sessionDataPath Prid,
sessionBinding ReferenceId,
sessionAccessor ReferenceId
} }
sessionId OBJECT-TYPE eventId OBJECT-TYPE
SYNTAX InstanceId SYNTAX InstanceId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An index to uniquely identify an instance of this "An index to uniquely identify this event."
provisioning class."
::= { sessionEntry 1 } ::= { eventEntry 1 }
sessionStatus OBJECT-TYPE eventEventHdlr OBJECT-TYPE
SYNTAX INTEGER { SYNTAX ReferenceId
Pending(0), PIB-REFERENCES { frwkReferenceEntry }
Enabled(1),
Disabled(2)
}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute is set by the PDP. Set to true(1) if the "This attribute allows a PEP to indicate to the PDP that
PDP has authorized the session, else set to false(2)." this event was generated due to the referenced Event
Handler. This attribute references an event handler via
the indirection PRC frwkReference, since the event
handler and event could potentially belong to a different
PIB contexts."
::= { sessionEntry 2 } ::= { eventEntry 2 }
sessionRealm OBJECT-TYPE eventCause OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX ReferenceId
PIB-REFERENCES { frwkReferenceEntry }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Realm name in which the client is requesting "This attribute references the specific instance in a
access (sometimes referred to as a domain name." group of event Handler elements belonging to an event
Handler that resulted in this event. This attribute
references a specific event handler element via the
indirection PRC frwkReference, since the event handler
element and event could potentially belong to a different
PIB contexts."
::= { sessionEntry 3 } ::= { eventEntry 3 }
sessionUsername OBJECT-TYPE --
SYNTAX OCTET STRING -- EventHandler Table
--
-- Instances of this PRC are provisioned by the PDP on the PEP
-- to catch specific events. The Event Handlers reference a
-- group of eventHdlrElement PRIs that contain the scope of
-- the event and specify the context data to send to the PDP
-- when an event is caught.
eventHandlerTable OBJECT-TYPE
SYNTAX SEQUENCE OF EventHandlerEntry
PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Unique user name to identify the client requesting "The eventHandlerTable specifies for what events the PEP
access." should send a request to the PDP. As a result of this
request, the PEP may send configuration changes to the
PEP. An instance of this class defines the circumstances
for generating a request, and provides the means for
specifying the contents of the PEP Request. Hence, the
eventHandlerTable can be said to create eventTable
entries. "
::= { sessionEntry 4 } ::= { eventHdlrClasses 1 }
sessionDataPath OBJECT-TYPE eventHandlerEntry OBJECT-TYPE
SYNTAX Prid SYNTAX EventHandlerEntry
STATUS current STATUS current
DESCRIPTION
"eventTable entry."
PIB-INDEX { eventHandlerId }
UNIQUENESS { eventHandlerElements,
eventHandlerNonMatchNext
}
Weiss et al. Expires October 2000 [Page 46] ::= { eventHandlerTable 1}
EventHandlerEntry ::= SEQUENCE {
eventHandlerId InstanceId,
eventHandlerElements TagReferenceId,
eventHandlerNonMatchNext Prid
}
eventHandlerId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION DESCRIPTION
"This attribute references the first functional data path "An arbitrary integer index that uniquely identifies
element to process data flow for this session. It is an instance of the eventHandlerTable class."
first assigned by the PEP with the
accessorElementDefaultSessionDataPath in the
accessorElement and may optionally be reassigned by the
PDP."
::= { sessionEntry 5 } ::= { eventHandlerEntry 1}
sessionBinding OBJECT-TYPE eventHandlerElements OBJECT-TYPE
SYNTAX ReferenceId SYNTAX TagReferenceId
PIB-REFERENCES { sessionEntry } PIB-TAG { eventHdlrElementGrpId }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute allows a PEP to indicate to the PDP that "A reference to a group of eventHdlrElement instances,
this session was generated downstream on the data path each of which determines the scope (criteria for
from a session for which an PEP has previously generated generating a new request) and what context information to
an authorization request. This allows the PDP to send in a request."
reference additional knowledge acquired from the previous
session such as the credentials or interface data. "
::= { sessionEntry 6 } ::= { eventHandlerEntry 2}
sessionAccessor OBJECT-TYPE eventHandlerNonMatchNext OBJECT-TYPE
SYNTAX ReferenceId SYNTAX Prid
PIB-REFERENCES { accessorEntry }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute references the instance of the previously "The data path for 'out of scope' traffic."
provisioned Accessor that resulted in this PEP Access
Request."
::= { sessionEntry 7 } ::= { eventHandlerEntry 3}
-- --
-- Accessor Table -- EventHdlrElement Table
-- --
-- Each Instance of this PRC belongs to a group of
-- eventHdlrElement PRIs. The group is identified by the
-- eventHdlrElementGrpId attribute. These are provisioned by
-- the PDP on the PEP to catch specific events. This PRC
-- contain the scope of the event and specify the context data
-- type to send to the PDP when an event is caught.
accessorTable OBJECT-TYPE eventHdlrElementTable OBJECT-TYPE
SYNTAX SEQUENCE OF AccessorEntry SYNTAX SEQUENCE OF EventHdlrElementEntry
PIB-ACCESS install PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The AccessorTable identifies when the PEP should send an "The eventHdlrElementTable specifies a single eventHdlr
access or authentication request to the PDP. As a element's scope via a reference to a group of filters and
result of this request, a new session may be started. the context data type and encapsulation meta-information
Hence, the AccessorTable can be said to create or remove that the PEP needs to send an event notification to the
SessionTable entries. " PDP."
Weiss et al. Expires October 2000 [Page 47] ::= { eventHdlrClasses 2 }
::= { accessorClasses 1 }
accessorEntry OBJECT-TYPE eventHdlrElementEntry OBJECT-TYPE
SYNTAX AccessorEntry SYNTAX EventHdlrElementEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
" An instance of this class defines the circumstances for "eventTable entry."
generating an access request, and provides the means for PIB-INDEX { eventHdlrElementId }
specifying the contents of the PEP Access Request." UNIQUENESS { eventHdlrElementEventCriteria,
PIB-INDEX { accessorId } eventHdlrElementGrpId,
UNIQUENESS { accessorRequestAuth, eventHdlrElementEventScope,
accessorAccElmRef, eventHdlrElementHandleScope,
accessorAuthProtocol, eventHdlrElementContext,
accessorAuthContext, eventHdlrElementMatchNext
accessorDefaultDataPath
} }
::= { accessorTable 1} ::= { eventHdlrElementTable 1}
AccessorEntry::= SEQUENCE { EventHdlrElementEntry ::= SEQUENCE {
accessorId InstanceId, eventHdlrElementId InstanceId,
accessorRequestAuth TruthValue, eventHdlrElementEventCriteria Unsigned32,
accessorAccElmRef ReferenceId, eventHdlrElementGrpId TagId,
accessorAuthProtocol TagReferenceId, eventHdlrElementEventScope TagReferenceId,
accessorAuthContext TagReferenceId, eventHdlrElementHandleScope TagReferenceId,
accessorDefaultDataPath Prid eventHdlrElementContext TagReferenceId,
eventHdlrElementMatchNext Prid
} }
accessorId OBJECT-TYPE eventHdlrElementId OBJECT-TYPE
SYNTAX InstanceId SYNTAX InstanceId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
" An arbitrary integer index that uniquely identifies " An arbitrary integer index that uniquely identifies
an instance of the accessorTable class." an instance of the eventHdlrElementTable class."
::= { accessorEntry 1} ::= { eventHdlrElementEntry 1}
accessorRequestAuth OBJECT-TYPE eventHdlrElementEventCriteria OBJECT-TYPE
SYNTAX TruthValue SYNTAX Unsigned32 {
one_time(1),
every_time(2),
on_change(3)
}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Indicates whether or not authentication is required for "Indicates when an event is generated. Valid options are
this session. TRUE indicates that authorization is one_time, every_time and on_change. This attribute allows
required." event Handlers to distinguish one time events (ignore
after the first match) from recurring events (generate an
event every time a match occurs). A enum type was also
define to specify that a new event should be generated
when a specific set of fields change. This is important
for protocols like RSVP because messages are sent both to
demonstrate that the reservation is active and to notify
hops of changes to reservations. Since only changes need
to propagate to the PDP, the on_change option indicates
that that events should be generated selectively.
::= { accessorEntry 2} This criteria controls behavior of both, the EventScope
and the HandleScope."
accessorAccElmRef OBJECT-TYPE ::= { eventHdlrElementEntry 2}
SYNTAX ReferenceId
PIB-REFERENCES { accessorElementEntry } eventHdlrElementGrpId OBJECT-TYPE
SYNTAX TagId -- corresponding Tag Reference in
-- eventHandlerEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A reference to an AccessorElementTable instance which "Group identifier. All instances with the same group
identifier belong to one group and can be referenced
collectively from an eventHandler instance."
Weiss et al. Expires October 2000 [Page 48] ::= { eventHdlrElementEntry 3}
determines the scope (criteria for generating a new
request) and interim forwarding behavior."
::= { accessorEntry 3} eventHdlrElementEventScope OBJECT-TYPE
SYNTAX TagReferenceId
PIB-TAG { eventHdlrEventScopeGroup }
STATUS current
DESCRIPTION
"Identifies a group of eventHdlrEventScope entries
associated with this eventHdlrElement instance."
accessorAuthProtocol OBJECT-TYPE ::= { eventHdlrElementEntry 4}
eventHdlrElementHandleScope OBJECT-TYPE
SYNTAX TagReferenceId SYNTAX TagReferenceId
PIB-TAG { accessorAuthProtocolGroup } PIB-TAG { eventHdlrHandleScopeGroup }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Identifies a list of accessorAuthProtocolTable entries "Identifies a group of eventHdlrHandleScope entries
associated with this accessor instance." associated with this eventHdlrElement instance. This is
an optional attribute. If it is not present the
semantics of the Handle processing is interpreted as
identical to the Event Scope handling specified in the
EventScope objects"
::= { accessorEntry 4} ::= { eventHdlrElementEntry 5}
accessorAuthContext OBJECT-TYPE eventHdlrElementContext OBJECT-TYPE
SYNTAX TagReferenceId SYNTAX TagReferenceId
PIB-TAG { contextDataGroup } PIB-TAG { contextDataGroup }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Identifies a list of ContextDataTable entries "Identifies a list of ContextDataTable entries
associated with this accessor instance." associated with this eventHdlrElement instance."
::= { accessorEntry 5} ::= { eventHdlrElementEntry 6}
accessorDefaultDataPath OBJECT-TYPE eventHdlrElementMatchNext OBJECT-TYPE
SYNTAX Prid SYNTAX Prid
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The data path for Šout of scopeĂ traffic." "The data path for traffic in scope."
::= { accessorEntry 6} ::= { eventHdlrElementEntry 7}
-- --
-- AccessorElement Table -- EventHdlrEventScope Table
-- --
-- This PRC defines the scope of an event handler element using
-- references to filters defined in the Framework PIB or in some
-- other PIBs. These filters may describe specific protocol
-- properties for which events need to be generated. These filter
-- references are grouped using a TagId, and this group is then
-- referenced from the eventHdlrElement PRC.
accessorElementTable OBJECT-TYPE eventHdlrEventScopeTable OBJECT-TYPE
SYNTAX SEQUENCE OF AccessorElementEntry SYNTAX SEQUENCE OF EventHdlrEventScopeEntry
PIB-ACCESS install PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This table defines the criteria to be used to generate "This class defines the criteria to be used for
an access request. It also defines the interim forwarding partitioning various portions of traffic."
behavior pending a decision from the server."
::= { accessorClasses 2 }
accessorElementEntry OBJECT-TYPE ::= { eventHdlrClasses 3 }
SYNTAX AccessorElementEntry
eventHdlrEventScopeEntry OBJECT-TYPE
SYNTAX EventHdlrEventScopeEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class defines request trigger "An instance of this class defines an individual criterion
criteria and interim forwarding behavior for packets." to be used towards generating an event."
PIB-INDEX { eventHdlrEventScopeId }
Weiss et al. Expires October 2000 [Page 49] UNIQUENESS { eventHdlrEventScopeGroup,
PIB-INDEX { accessorElementId } eventHdlrEventScopeFilter
UNIQUENESS { accessorElementScope } }
::= { eventHdlrEventScopeTable 1}
::= { accessorElementTable 1}
AccessorElementEntry::= SEQUENCE { EventHdlrEventScopeEntry::= SEQUENCE {
accessorElementId InstanceId, eventHdlrEventScopeId InstanceId,
accessorElementScope TagReferenceId, eventHdlrEventScopeGroup TagId,
accessorElementInterimFwdBehavior INTEGER, eventHdlrEventScopeFilter Prid,
accessorElementDefaultSessionDataPath Prid eventHdlrEventScopePrecedence INTEGER,
eventHdlrEventScopeChangeFlag TruthValue
} }
accessorElementId OBJECT-TYPE eventHdlrEventScopeId OBJECT-TYPE
SYNTAX InstanceId SYNTAX InstanceId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An arbitrary integer index that uniquely identifies an "An arbitrary integer index that uniquely identifies an
instance of the accessorElementTable class." instance of the eventHdlrEventScopeTable class."
::= { accessorElementEntry 1} ::= { eventHdlrEventScopeEntry 1}
accessorElementScope OBJECT-TYPE eventHdlrEventScopeGroup OBJECT-TYPE
SYNTAX TagReferenceId SYNTAX TagId -- corresponding TagReference
PIB-TAG { accessorSessionScopeGroup } -- defined in eventHdlrElementEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Identifies a list of AccessorSessionScopeTable instances "Represents the binding between the eventHdlrElementEntry
associated with an instance of this class. This list and the eventHdlrEventScope entries. A group of
defines the criteria for partitioning various portions of eventHdlrEventScope entries constitutes the criteria for
traffic into distinct sessions." partitioning various portions of traffic."
::= { accessorElementEntry 2} ::= { eventHdlrEventScopeEntry 2}
accessorElementInterimFwdBehavior OBJECT-TYPE eventHdlrEventScopeFilter OBJECT-TYPE
SYNTAX INTEGER { SYNTAX Prid
DROP (0),
FORWARD (1),
QUEUE (2)
}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The forwarding behavior to use while awaiting a PDP "Pointer to a filter to be used as the criteria."
Access Response message." ::= { eventHdlrEventScopeEntry 3}
::= { accessorElementEntry 3} eventHdlrEventScopePrecedence OBJECT-TYPE
SYNTAX INTEGER
STATUS current
DESCRIPTION
"Represents the precedence of this criterion with respect
to other criteria within the same group. When the
precedence is unique, the instance represents an
alternative criteria (an ORing function). When the
precedence for two or more instances of the
eventHdlrEventScope class is the same, the attributes
within all the instances are treated collectively as a
single filter criteria with the following rules:
1. If the filters are not of the same type, the filters
are ANDĂed as a whole eg (RSVP and IP)
2. If the filter types are the same, the attribute values
are ORĂed and the attributes themselves are ANDĂed,
for example, two IP filters with src protocol values
56 and 57 respectively and dst protocol values 20 and
25 , would be treated as the condition (src port (56
or 57) AND dst port (20 or 25)."
accessorElementDefaultSessionDataPath OBJECT-TYPE ::= { eventHdlrEventScopeEntry 4}
SYNTAX Prid
eventHdlrEventScopeChangeFlag OBJECT-TYPE
SYNTAX TruthValue
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The default data path for each session while waiting for "Boolean value, if set to 'true' indicates that a new
a event should be generated if any of the assigned fields in
PDP Access Response message." the associated filter change."
Weiss et al. Expires October 2000 [Page 50] ::= { eventHdlrEventScopeEntry 5}
::= { accessorElementEntry 4}
-- --
-- AccessorSessionScope Table -- EventHdlrHandleScope Table
-- --
-- This PRC defines the scope of request handles generated by the
-- PEP due to events caught by the event handler element. Each
-- instance of this PRC references filters defined in the
-- Framework PIB or some other signaling-protocol specific filter
-- PRCs. These filters may describe specific protocol properties
-- to which this event handler is sensitive. Essentially this
-- table defines when a new COPS RequestHandle must be created by
-- the PEP based on protocol properties. The event handler may be
-- set up to be sensitive to specific field values and/or the
-- uniqueness of a set of values considered together. This
-- accommodates various behaviors of signaling protocols. These
-- filters references are grouped using a TagId, and this group
-- is then referenced from the eventHdlrElement PRC via the
-- eventHdlrElementHandleScope TagReference.
accessorSessionScopeTable OBJECT-TYPE eventHdlrHandleScopeTable OBJECT-TYPE
SYNTAX SEQUENCE OF AccessorSessionScopeEntry SYNTAX SEQUENCE OF EventHdlrHandleScopeEntry
PIB-ACCESS install PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This class defines the criteria to be used for "This class defines the criteria to be used for
partitioning various portions of traffic into distinct deciding whether to create a new COPS RequestHandle for
sessions." an event or to use an existing Handle."
::= { accessorClasses 3 } ::= { eventHdlrClasses 4 }
accessorSessionScopeEntry OBJECT-TYPE eventHdlrHandleScopeEntry OBJECT-TYPE
SYNTAX AccessorSessionScopeEntry SYNTAX EventHdlrHandleScopeEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class defines an individual criterion "An instance of this class defines an individual criterion
to be used towards generating an access request." to be used towards deciding when to create a new Handle."
PIB-INDEX { accessorSessionScopeId } PIB-INDEX { eventHdlrHandleScopeId }
UNIQUENESS { accessorSessionScopeGroup, UNIQUENESS { eventHdlrHandleScopeGroup,
accessorSessionScopeScopeRef eventHdlrHandleScopeFilter
} }
::= { accessorSessionScopeTable 1} ::= { eventHdlrHandleScopeTable 1}
AccessorSessionScopeEntry::= SEQUENCE { EventHdlrHandleScopeEntry::= SEQUENCE {
accessorSessionScopeId InstanceId, eventHdlrHandleScopeId InstanceId,
accessorSessionScopeGroup TagId, eventHdlrHandleScopeGroup TagId,
accessorSessionScopeFilter Prid, eventHdlrHandleScopeFilter Prid,
accessorSessionScopePrecedence INTEGER eventHdlrHandleScopePrecedence INTEGER,
eventHdlrHandleScopeChangeFlag TruthValue
} }
accessorSessionScopeId OBJECT-TYPE eventHdlrHandleScopeId OBJECT-TYPE
SYNTAX InstanceId SYNTAX InstanceId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An arbitrary integer index that uniquely identifies an "An arbitrary integer index that uniquely identifies an
instance of the accessorSessionScopeTable class." instance of the eventHdlrHandleScopeTable class."
::= { accessorSessionScopeEntry 1} ::= { eventHdlrHandleScopeEntry 1}
accessorSessionScopeGroup OBJECT-TYPE eventHdlrHandleScopeGroup OBJECT-TYPE
SYNTAX TagId SYNTAX TagId -- corresponding TagReference
-- defined in eventHdlrElementEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents the binding between the accessorElementTable "Represents the binding between the eventHdlrElementEntry
and the accessorSessionScope entries. A group of and the eventHdlrHandleScope entries. A group of
eventHdlrHandleScope entries constitutes the criteria for
Weiss et al. Expires October 2000 [Page 51] defining the scope of the Handles generated."
accessorSessionScope entries constitutes the criteria for
partitioning various portions of traffic into distinct
sessions."
::= { accessorSessionScopeEntry 2} ::= { eventHdlrHandleScopeEntry 2}
accessorSessionScopeFilter OBJECT-TYPE eventHdlrHandleScopeFilter OBJECT-TYPE
SYNTAX Prid SYNTAX Prid
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Pointer to a filter to be used as the criteria." "Pointer to a filter to be used as the criteria."
::= { accessorSessionScopeEntry 3} ::= { eventHdlrHandleScopeEntry 3}
accessorSessionScopePrecedence OBJECT-TYPE eventHdlrHandleScopePrecedence OBJECT-TYPE
SYNTAX INTEGER SYNTAX INTEGER
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents the precedence of this criterion with respect "Represents the precedence of this criterion with respect
to other criteria within the same group. When the to other criteria within the same group. When the
precedence is unique, the instance represents an precedence is unique, the instance represents an
alternative criteria (an ORing function). When the alternative criteria (an ORing function). When the
precedence for two or more instances of the precedence for two or more instances of the
accessorSessionScope class is the same, the attributes eventHdlrHandleScope class is the same, the attributes
within all the instances are treated collectively as a within all the instances are treated collectively as a
single filter criteria." single filter criteria."
::= { accessorSessionScopeEntry 4} ::= { eventHdlrHandleScopeEntry 4}
eventHdlrHandleScopeChangeFlag OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Boolean value, if set to 'true' indicates that a new
Handle should be generated to send the event request if
any of the assigned fields in the associated filter
change."
::= { eventHdlrHandleScopeEntry 5}
-- --
-- AccessorAuthProtocol Table -- EventHdlrAuthProtocol Table
-- --
-- This PRC specifies the Auth Mechanism to use in the Access
-- request when a data path Event Handler is configured to
-- catch access events.
accessorAuthProtocolTable OBJECT-TYPE eventHdlrAuthProtocolTable OBJECT-TYPE
SYNTAX SEQUENCE OF AccessorAuthProtocolEntry SYNTAX SEQUENCE OF EventHdlrAuthProtocolEntry
PIB-ACCESS install PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This class lists the authentication protocols that can "This class lists the authentication protocols that can
be used for an access request originating from a be used for an access request."
particular instance of the accessorTable."
::= { accessorClasses 4 } ::= { eventHdlrClasses 5 }
accessorAuthProtocolEntry OBJECT-TYPE eventHdlrAuthProtocolEntry OBJECT-TYPE
SYNTAX AccessorAuthProtocolEntry SYNTAX EventHdlrAuthProtocolEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class describes an authentication "An instance of this class describes an authentication
protocol that may be used for an access request. Instances protocol that may be used for an access request. Instances
Weiss et al. Expires October 2000 [Page 52]
of this class that share the same TagId value collectively of this class that share the same TagId value collectively
constitute a list of authentication protocols that may be constitute a list of authentication protocols that may be
used for a given access request" used for a given access request"
PIB-INDEX { accessorAuthProtocolId } PIB-INDEX { eventHdlrAuthProtocolId }
UNIQUENESS { accessorAuthProtocolGroup, UNIQUENESS { eventHdlrAuthProtocolGroup,
accessorAuthProtocolAuthMechanism eventHdlrAuthProtocolAuthMechanism
} }
::= { eventHdlrAuthProtocolTable 1}
::= { accessorAuthProtocolTable 1} EventHdlrAuthProtocolEntry::= SEQUENCE {
eventHdlrAuthProtocolId InstanceId,
AccessorAuthProtocolEntry::= SEQUENCE { eventHdlrAuthProtocolGroup TagId,
accessorAuthProtocolId InstanceId, eventHdlrAuthProtocolAuthMechanism INTEGER
accessorAuthProtocolGroup TagId,
accessorAuthProtocolAuthMechanism INTEGER
} }
accessorAuthProtocolId OBJECT-TYPE eventHdlrAuthProtocolId OBJECT-TYPE
SYNTAX InstanceId SYNTAX InstanceId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An arbitrary integer index that uniquely identifies an "An arbitrary integer index that uniquely identifies an
instance of the ContextDataTable class." instance of the ContextDataTable class."
::= { accessorAuthProtocolEntry 1} ::= { eventHdlrAuthProtocolEntry 1}
accessorAuthProtocolGroup OBJECT-TYPE eventHdlrAuthProtocolGroup OBJECT-TYPE
SYNTAX TagId SYNTAX TagId -- corresponding TagReference
-- in datapathEventHdlrEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a binding between an accessorTable instance "Represents a binding between an datapathEventHdlrTable
and a list of accessorAuthProtocolTable instances." instance and a list of eventHdlrAuthProtocolTable
instances."
::= { accessorAuthProtocolEntry 2} ::= { eventHdlrAuthProtocolEntry 2}
accessorAuthProtocolAuthMechanism OBJECT-TYPE eventHdlrAuthProtocolAuthMechanism OBJECT-TYPE
SYNTAX INTEGER { SYNTAX INTEGER {
PAP (0), PAP (0),
CHAP (1), CHAP (1),
EAP-MD5(2), EAP_MD5(2),
EAP-TLS(3) EAP_TLS(3)
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The authentication protocol that may be used for an "The authentication protocol that may be used for an
access request." access request."
::= { accessorAuthProtocolEntry 3} ::= { eventHdlrAuthProtocolEntry 3}
--
-- DataPath Event Handler Table
--
-- This PRC is an extension of the EventHandler PRC. This
-- extension illustrates the use of the EventHandler PRC
-- concept for authentication usage. Instances of this PRC are
-- provisioned by the PDP on the PEP to catch specific access
-- events. This PRC references a group of
-- eventHdlrAuthProtocol instances which define a set of
-- Authentication mechanisms to use if an access event is
-- caught by this event Handler. From its base class (Event
-- Handler) this PRC also references a group of
-- eventHdlrElement PRIs that contain the scope of the
-- access event and specify the context data to send to the
-- PDP when an access event is caught.
datapathEventHdlrTable OBJECT-TYPE
SYNTAX SEQUENCE OF DatapathEventHdlrEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"The datapathEventHdlrTable specifies for what access
events the PEP should send an access request to the PDP.
As a result of this access request, the PEP may send
configuration changes to the PEP or specific policies for
specific users. An instance of this class defines the
circumstances for generating an access request, and
provides the means for specifying the authentication
mechanisms and contents of the PEP Request. Hence, the
datapathEventHdlrTable can be said to create eventTable
entries for user access. "
::= { eventHdlrClasses 6 }
datapathEventHdlrEntry OBJECT-TYPE
SYNTAX DatapathEventHdlrEntry
STATUS current
DESCRIPTION
"dataPathEventHdlrTable entry."
EXTENDS { EventHandlerEntry }
UNIQUENESS { eventHandlerElements,
eventHandlerNonMatchNext,
datapathEventHdlrRequestAuth
}
::= { datapathEventHdlrTable 1}
DatapathEventHdlrEntry ::= SEQUENCE {
datapathEventHdlrRequestAuth TruthValue,
datapathEventHdlrAuthProtocol TagReferenceId
}
datapathEventHdlrRequestAuth OBJECT-TYPE
SYNTAX TruthValue
STATUS current
DESCRIPTION
"Boolean flag, if set to 'true' requires authentication
data to be sent in the request sent to the PDP with the
access event."
::= { datapathEventHdlrEntry 1}
datapathEventHdlrAuthProtocol OBJECT-TYPE
SYNTAX TagReferenceId
PIB-TAG { eventHdlrAuthProtocolGroup }
STATUS current
DESCRIPTION
"References a group of eventHdlrAuthProtocol instances,
each of which specifies an authentication mechanism."
::= { datapathEventHdlrEntry 2}
-- --
-- ContextData Table -- ContextData Table
-- --
-- This PRC specifies the context information to send to the PDP
-- when an event is caught. The context information to send is
-- described in terms of the PRC data types to include in the
-- request, the level of encapsulated data and the interface
-- information for that request.
Weiss et al. Expires October 2000 [Page 53]
contextDataTable OBJECT-TYPE contextDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF ContextDataEntry SYNTAX SEQUENCE OF ContextDataEntry
PIB-ACCESS install PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This class points to the context information to be "This class points to the context information to be
included with an access request." included with a request."
::= { contextClasses 1 } ::= { contextClasses 1 }
contextDataEntry OBJECT-TYPE contextDataEntry OBJECT-TYPE
SYNTAX ContextDataEntry SYNTAX ContextDataEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class contains the type description "An instance of this class contains the type description
(COPS-PR OID) of the class which needs to be filled in by (the assigned OID) of the class which needs to be filled
the PEP and included with a PEP access request." in by the PEP and included with a PEP request."
PIB-INDEX { contextDataId } PIB-INDEX { contextDataId }
UNIQUENESS { } UNIQUENESS { }
::= { contextDataTable 1} ::= { contextDataTable 1}
ContextDataEntry::= SEQUENCE { ContextDataEntry::= SEQUENCE {
contextDataId InstanceId, contextDataId InstanceId,
contextDataGroup TagId, contextDataGroup TagId,
contextDataSessionRef ReferenceId,
contextDataIfElement PrcIdentifier, contextDataIfElement PrcIdentifier,
contextDataEncapsulation INTEGER contextDataEncapsulation INTEGER
} }
contextDataId OBJECT-TYPE contextDataId OBJECT-TYPE
SYNTAX InstanceId SYNTAX InstanceId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An arbitrary integer index that uniquely identifies an "An arbitrary integer index that uniquely identifies an
instance of the contextDataTable class." instance of the contextDataTable class."
::= { contextDataEntry 1} ::= { contextDataEntry 1}
contextDataGroup OBJECT-TYPE contextDataGroup OBJECT-TYPE
SYNTAX TagId SYNTAX TagId --corresponding TagReference
--defined in eventHdlrElement
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Defines the grouping of contextData instances "Defines the grouping of contextData instances
that are applicable to a given Accessor. This attribute that are applicable to a given eventHdlrElement. When
MUST NOT be specified when the instance is used in instances of this PRC are sent to the PEP without the
Session-specific contextData Request message." event Handler information, this attribute is unused."
::= { contextDataEntry 2} ::= { contextDataEntry 2}
contextDataSessionRef OBJECT-TYPE
SYNTAX ReferenceId
Weiss et al. Expires October 2000 [Page 54]
PIB-REFERENCES { sessionEntry }
STATUS current
DESCRIPTION
"This attribute is used to specify the Session for which
the ContextData is being requested with a Session-
specific ContextData Request. This attribute MUST NOT be
specified when the instance of the ContextData class is
used in an Accessor Provisioning Decision message."
::= { contextDataEntry 3}
contextDataIfElement OBJECT-TYPE contextDataIfElement OBJECT-TYPE
SYNTAX PrcIdentifier SYNTAX PrcIdentifier
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The OID of a class whose instance is to be included with "The OID of a class whose instance is to be included with
the PEP access request or Session-specific ContextData the PEP request or event-specific ContextData Response."
Response."
::= { contextDataEntry 4} ::= { contextDataEntry 3}
contextDataEncapsulation OBJECT-TYPE contextDataEncapsulation OBJECT-TYPE
SYNTAX INTEGER SYNTAX INTEGER
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute allows one to distinguish between inner "This attribute allows one to distinguish between inner
and outer headers when there are multiple encapsulated and outer headers when there are multiple encapsulated
headers of the same type in a packet. headers of the same type in a packet.
A value of: A value of:
0 means all headers, 0 means all headers,
positive number ŠnĂ means the ŠnĂth header starting positive number 'n' means the 'n'th header starting
from the outermost, from the outermost,
negative number ŠnĂ means the ŠnĂth header starting from negative number 'n' means the 'n'th header starting from
the innermost." the innermost."
::= { contextDataEntry 5} ::= { contextDataEntry 4}
-- --
-- Layer 3 Header Data PRC -- Layer 3 Header Data PRC
-- --
ctxtL3HdrTable OBJECT-TYPE ctxtL3HdrTable OBJECT-TYPE
SYNTAX SEQUENCE OF ctxtL3HdrEntry SYNTAX SEQUENCE OF ctxtL3HdrEntry
PIB-ACCESS notify PIB-ACCESS notify
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class is created by the PEP and sent "An instance of this class is created by the PEP and
to the PDP to provide the PDP with information it sent to the PDP to provide the PDP with information it
requested in the ContextData PRC. The PDP uses requested in the ContextData PRC. The PDP uses
this PRC to make Authentication/Provisioning decisions." this PRC to make Authentication/Provisioning
decisions."
Weiss et al. Expires October 2000 [Page 55]
::= { contextClasses 2 } ::= { contextClasses 2 }
ctxtL3HdrEntry OBJECT-TYPE ctxtL3HdrEntry OBJECT-TYPE
SYNTAX CtxtL3HdrEntry SYNTAX CtxtL3HdrEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of the ctxtL3HdrTable PRC." "An instance of the ctxtL3HdrTable PRC."
PIB-INDEX { ctxtL3HdrId } PIB-INDEX { ctxtL3HdrId }
UNIQUENESS { } UNIQUENESS { }
skipping to change at line 2853 skipping to change at page 71, line 38
ctxtL3HdrId InstanceId, ctxtL3HdrId InstanceId,
ctxtL3HdrSrcAddrType InetAddressType, ctxtL3HdrSrcAddrType InetAddressType,
ctxtL3HdrSrcAddr InetAddress, ctxtL3HdrSrcAddr InetAddress,
ctxtL3HdrDstAddrType InetAddressType, ctxtL3HdrDstAddrType InetAddressType,
ctxtL3HdrDstAddr InetAddress, ctxtL3HdrDstAddr InetAddress,
ctxtL3HdrProtocol Unsigned32, ctxtL3HdrProtocol Unsigned32,
ctxtL3HdrSrcPort Unsigned32, ctxtL3HdrSrcPort Unsigned32,
ctxtL3HdrDstPort Unsigned32, ctxtL3HdrDstPort Unsigned32,
ctxtL3HdrDscp Unsigned32, ctxtL3HdrDscp Unsigned32,
ctxtL3HdrEcn TruthValue, ctxtL3HdrEcn TruthValue,
ctxtL3HdrIpOpt TruthValue, ctxtL3HdrIpOpt OCTET STRING,
ctxtL3HdrEncap Integer32 ctxtL3HdrEncap Integer32
} }
ctxtL3HdrId OBJECT-TYPE ctxtL3HdrId OBJECT-TYPE
SYNTAX InstanceId SYNTAX InstanceId
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An index to uniquely identify an instance of this "An index to uniquely identify an instance of this
provisioning class." provisioning class."
skipping to change at line 2872 skipping to change at page 72, line 4
provisioning class." provisioning class."
::= { ctxtL3HdrEntry 1 } ::= { ctxtL3HdrEntry 1 }
ctxtL3HdrSrcAddrType OBJECT-TYPE ctxtL3HdrSrcAddrType OBJECT-TYPE
SYNTAX InetAddressType SYNTAX InetAddressType
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The address type enumeration value [INETADDR] to specify "The address type enumeration value [INETADDR] to specify
the type of the packet's source L3 address)." the type of the packet's source L3 address)."
::= { ctxtL3HdrEntry 2 } ::= { ctxtL3HdrEntry 2 }
ctxtL3HdrSrcAddr OBJECT-TYPE ctxtL3HdrSrcAddr OBJECT-TYPE
SYNTAX InetAddress SYNTAX InetAddress
STATUS current STATUS current
DESCRIPTION DESCRIPTION
" The packet's source L3 address." " The packet's source L3 address."
Weiss et al. Expires October 2000 [Page 56]
::= { ctxtL3HdrEntry 3 } ::= { ctxtL3HdrEntry 3 }
ctxtL3HdrDstAddrType OBJECT-TYPE ctxtL3HdrDstAddrType OBJECT-TYPE
SYNTAX InetAddressType SYNTAX InetAddressType
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The address type enumeration value [INETADDR] to specify "The address type enumeration value [INETADDR] to specify
the type of the packet's destination L3 address." the type of the packet's destination L3 address."
::= { ctxtL3HdrEntry 4 } ::= { ctxtL3HdrEntry 4 }
skipping to change at line 2924 skipping to change at page 73, line 4
this session instance." this session instance."
::= { ctxtL3HdrEntry 7 } ::= { ctxtL3HdrEntry 7 }
ctxtL3HdrDstPort OBJECT-TYPE ctxtL3HdrDstPort OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This attribute binds an existing upstream session to "This attribute binds an existing upstream session to
this session instance." this session instance."
::= { ctxtL3HdrEntry 8 } ::= { ctxtL3HdrEntry 8 }
ctxtL3HdrDscp OBJECT-TYPE ctxtL3HdrDscp OBJECT-TYPE
SYNTAX Unsigned32 SYNTAX Unsigned32
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"." "DiffServ CodePoint."
Weiss et al. Expires October 2000 [Page 57]
::= { ctxtL3HdrEntry 9 } ::= { ctxtL3HdrEntry 9 }
ctxtL3HdrEcn OBJECT-TYPE ctxtL3HdrEcn OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"PEP sets this attribute to true(1) if ECN capable." "PEP sets this attribute to true(1) if ECN capable."
::= { ctxtL3HdrEntry 10 } ::= { ctxtL3HdrEntry 10 }
skipping to change at line 2967 skipping to change at page 73, line 45
being described. The sign on this value will be the same being described. The sign on this value will be the same
as the value specified in the ContextData as the value specified in the ContextData
instance that requested this header. If the original instance that requested this header. If the original
ContextData instance specified a ContextData instance specified a
ContextDataEncapsulation value of zero (meaning ContextDataEncapsulation value of zero (meaning
return all headers), then all instances of this attribute return all headers), then all instances of this attribute
MUST be expressed as positive numbers. MUST be expressed as positive numbers.
A value of: A value of:
positive number ŠnĂ means the ŠnĂth header starting positive number 'n' means the 'n'th header starting
from the outermost, from the outermost,
negative number ŠnĂ means the ŠnĂth header starting from negative number 'n' means the 'n'th header starting from
the innermost." the innermost."
::= { ctxtL3HdrEntry 12 } ::= { ctxtL3HdrEntry 12 }
-- --
-- 802.1 Header Data PRC -- 802.1 Header Data PRC
-- --
ctxt802HdrTable OBJECT-TYPE ctxt802HdrTable OBJECT-TYPE
SYNTAX SEQUENCE OF Ctxt802HdrEntry SYNTAX SEQUENCE OF Ctxt802HdrEntry
PIB-ACCESS notify PIB-ACCESS notify
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class is created by the PEP and sent "An instance of this class is created by the PEP and sent
to the PDP to provide the PDP with information it to the PDP to provide the PDP with information it
requested in the ContextData PRC. The PDP uses requested in the ContextData PRC. The PDP uses this PRC
to make Authorization/Provisioning decisions."
Weiss et al. Expires October 2000 [Page 58]
this PRC to make Authorization/Provisioning decisions."
::= { contextClasses 3 } ::= { contextClasses 3 }
ctxt802HdrEntry OBJECT-TYPE ctxt802HdrEntry OBJECT-TYPE
SYNTAX Ctxt802HdrEntry SYNTAX Ctxt802HdrEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of the ctxt802HdrTable PRC." "An instance of the ctxt802HdrTable PRC."
PIB-INDEX { ctxt802HdrId } PIB-INDEX { ctxt802HdrId }
UNIQUENESS { } UNIQUENESS { }
::= { ctxt802HdrTable 1 } ::= { ctxt802HdrTable 1 }