draft-ietf-rap-access-bind-01.txt   draft-ietf-rap-access-bind-02.txt 
Internet Engineering Task Force Walter Weiss Internet Engineering Task Force Walter Weiss
RAP Working Group Ellacoya Networks RAP Working Group Ellacoya Networks
Expiration: October 2002 John Vollbrecht Expiration: May 2003 John Vollbrecht
draft-ietf-rap-access-bind-01.txt David Spence draft-ietf-rap-access-bind-02.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 Ho 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: 3/1/02 Last Updated: 11/4/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 page 2, line 9 skipping to change at line 55
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].
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 Access Bind PIB................................6
2.1 Event Handler 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. Context Data.................................................10 2.1.2. Context Data...............................................10
2.3. Policy Distribution and Management...........................11 2.1.3. Policy Distribution and Management.........................11
2.4. Interactions with DiffServ model.............................11 2.2. Event Handlers and Application-Specific PIBs.................12
2.5. Interactions with RSVP model.................................12 2.3. Passive Monitoring vs. Programmatic API......................12
3. Supporting various client Authentication Protocols.............14 2.3.1. Interactions with DiffServ data path model.................13
3.1. Provisioning.................................................14 2.3.2. The Programmatic API to the Access Bind PIB................14
3.2. EAP Authentication...........................................15 3. Access Bind PIB................................................16
3.2.1. EAP Message sequence.......................................15 3.1. The Event Handler............................................16
3.2.2. AuthEapReqExt and AuthEapRespExt data structures...........17 3.1.1. Functional Description.....................................17
3.3. PAP Authentication...........................................17 3.1.2. Event Criteria behavior....................................18
3.3.1. PAP Connection sequence....................................18 3.1.3. Context Data usage.........................................19
3.3.2. AuthPapExtEntry datastructure..............................19 3.1.4. Data Description...........................................19
3.4. CHAP Authentication..........................................20 3.1.4.1. EventHandler class.......................................19
3.4.1. CHAP Connection sequence...................................20 3.1.4.2. EventHdlrElement class...................................20
3.4.2. AuthChapExtEntry datastructure.............................22 3.1.4.3. EventHdlrEventScope class................................22
3.5. HTTP Authentication..........................................23 3.1.4.4. EventHdlrHandleScope class...............................23
4. Data Structures................................................24 3.1.4.5. ContextData class........................................24
4.1. Event class..................................................24 3.2. Event Handling...............................................25
4.2. EventHandler class...........................................24 3.2.1. Functional Description.....................................25
4.3. EventHdlrElement class.......................................25 3.2.2. COPS Client Handle.........................................26
4.4. EventHdlrEventScope class....................................26 3.2.3. DiffServ element...........................................26
4.5. EventHdlrHandleScope class...................................28 3.2.4. Behavior of the Event and Handle Scope classes.............27
4.6. Behavior of the Event and Handle Scope classes...............29 3.2.5. Context Data Entries.......................................28
4.7. EventHdlrAuthProtocol class..................................30 3.2.6. Data Description...........................................28
4.8. DatapathEventHdlr Class......................................31 3.2.6.1. Event class..............................................29
4.9. ContextData class............................................31 3.2.6.2. ContextData classes......................................29
4.10. ContextData classes.........................................32 3.2.6.2.1. CtxtL3Hdr class........................................29
4.10.1. CtxtL3Hdr class...........................................32 3.2.6.2.2. Ctxt802Hdr class.......................................30
4.10.2. Ctxt802Hdr class..........................................33 4. Identity Extensions PIB module.................................32
4.10.3. CtxtDialupInterface class.................................34 4.1. Functional Description.......................................32
4.10.4 CtxtDialupIfFramedProtocol class...........................35 4.1.1. Provisioning...............................................32
4.10.5 CtxtDialupIfLoginService class.............................36 4.1.2. EAP Authentication.........................................33
4.10.6 CtxtDialupIfLoginLat class.................................36 4.1.2.1. EAP Message sequence.....................................33
4.11. AuthExt class...............................................37 4.1.3. PAP Authentication.........................................35
4.11.1. UserAuthExt class.........................................37 4.1.3.1. PAP Connection sequence..................................35
4.11.2. AuthChapExt class.........................................37 4.1.4. CHAP Authentication........................................36
4.11.3. AuthPapExt class..........................................38 4.1.4.1. CHAP Connection sequence.................................37
4.11.4. AuthExtResult class.......................................38 4.2. Data Description.............................................38
4.11.5. AuthEapReqExt class.......................................38 4.2.1. IdentityEventHdlr Class....................................38
4.11.6. AuthEapRespExt class......................................39 4.2.2. EventHdlrAuthProtocol class................................39
5. Message Types..................................................40 4.2.3. AuthExt class..............................................39
5.1. Event Handler Provisioning Decisions.........................40 4.2.4. UserAuthExt class..........................................40
5.2. Provisioning Decision........................................41 4.2.5. AuthExtResult class........................................40
5.3. PEP Event Message............................................41 4.2.6. AuthEapReqExt and AuthEapRespExt classes...................40
5.4. PDP Provisioning Decision....................................42 4.2.7. AuthPapExtEntry class......................................41
5.5. PDP fetching Event-specific ContextData......................42 4.2.8. AuthChapExtEntry class.....................................42
5.6. Event-specific ContextData Response..........................43 5. Signal Handling................................................43
5.7. Opaque Decision..............................................43 5.1 Functional Description........................................43
5.8. Opaque Report................................................43 5.2 Data Description..............................................43
6. Combining Data Structures in Messages..........................45 6. Programmatic Interface Between Signal and Event Handling.......44
6.1. Combining Context Data in Event Messages.....................45 6.1. Functional Description.......................................44
7. Access Bind Usage Examples.....................................46 6.2. Method Description...........................................45
7.1 Wireless LAN (802.11 Access Point) Usage Example..............46 6.3. Access Bind API Example......................................46
7.1.1 Wireless LAN Access Event Handler Provisioning..............47 7. Message Types..................................................49
7.1.2 Wireless LAN Access Event Handling..........................48 7.1. Event Handler Provisioning Decisions.........................49
7.1.3 Wireless LAN Access Event Decision..........................48 7.2. Provisioning Report..........................................50
7.2 RSVP Usage Example............................................49 7.3. PDP Provisioning Decision....................................51
8. The AccessBind PIB Module......................................56 7.4. PDP fetching Event-specific ContextData......................51
9. Security Considerations.......................................104 7.5. Event-specific ContextData Response..........................52
10. References...................................................105 7.6. Opaque Decision..............................................52
11. Author Information and Acknowledgments.......................106 7.7. Opaque Report................................................52
7.8. Combining Data Structures in Messages........................53
8. Access Bind Usage Examples.....................................54
8.1 Wireless LAN (802.11 Access Point) Usage Example..............54
8.1.1 Wireless LAN Access Event Handler Provisioning..............54
8.1.2 Wireless LAN Access Event Handling..........................54
8.1.3 Wireless LAN Access Event Decision..........................55
8.2 RSVP Usage Example............................................55
9. The AccessBind PIB Module......................................63
10. Identity Extensions PIB.......................................79
11. Application Specific RSVP Handling PIB Module.................90
12. Application Specific Dialup Handling PIB Module..............104
13. Security Considerations......................................115
14. References...................................................116
15. Author Information and Acknowledgments.......................117
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 page 4, line 50 skipping to change at line 179
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
PEP of the result. This separation of access control into two parts PEP of the result. This separation of access control into two parts
is necessary because invariably the PEP does not have the capacity is necessary because invariably the PEP does not have the capacity
to store all possible identities and credentials. This information to store all possible identities and credentials. This information
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 [RSVP]. When an RSVP service request is made, the
evaluates a set of criteria including what is being requested, what PDP evaluates a set of criteria including what is being requested,
the availability of specific resources are, the identity of the what 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
honored, specific provisioning actions may be taken to bound or honored, specific provisioning actions may be taken to bind 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 Events" to denote the fact that PEP is will be referred to as _PEP Events_ to denote the fact that PEP is
generating an event indicating a request for 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 Events, there In order to support the broad variety of potential PEP Events, there
must be a way of provisioning the criteria for generating the PEP must be a way of provisioning the criteria for generating the PEP
Event. In the most common case the PEP Event is generated as a Event. In the most common case the PEP Event is generated as the
result of some type of packet oriented event such as activity on a result of some type of packet oriented event such as activity on a
link, traffic of a particular type or traffic from a new, unknown IP link, traffic of a particular type or traffic from a new, unknown IP
address. address.
This leads to a useful observation: PEP Events need to be defined This leads to a useful observation: In many cases, PEP Events need
within the context of a network data path. In other words, the data to be defined within the context of a network data path. In other
path mechanisms defined in the DiffServ informal model [MODEL] and words, the data path mechanisms defined in the DiffServ informal
the DiffServ PIB [DSPIB] provide a means for specifying the model [MODEL] and the DiffServ PIB [DSPIB] provide a means for
circumstances for generating a PEP Event by reusing elements from specifying the circumstances for generating a PEP Event by reusing
the model like the qosDatapathTable table and the qosClfrTable table elements from the model like the qosDatapathTable table and the
in the DiffServ PIB. qosClfrTable table in the DiffServ PIB.
The second circumstance for generating an event from the PEP is
through a programmatic interface in between the PEP and an external
service such as the policy control interface in an RSVP service. In
these instances, this PIB is used to configure the PEP to accept
specific events through the API. Using COPS provisioning, a PEP can
be configured to generate events for one or more types of RSVP
events such as a new PATH request or a new RESV request.
Another consideration is the variety of information that can Another consideration is the variety of information that can
potentially be included in a PEP Event. For instance, a PEP Event potentially be included in a PEP Event. For instance, a PEP Event
could pass information about the client (domain), the physical port could pass information about the client (domain), the physical port
(dial up interface), L2 headers, L3 headers, encapsulation headers (dial up interface), L2 headers, L3 headers, encapsulation headers
(tunnels), cookies, and additional information already negotiated (tunnels), cookies, and additional information already negotiated
prior to generating the PEP Event. Given the amount of information prior to generating the PEP Event. Given the amount of information
that could be sent with the PEP Event, it is reasonable to allow the that could be sent with the PEP Event, it is reasonable to allow the
PDP to configure the PEP with the set of information the PDP would PDP to configure the PEP with the set of information the PDP would
like to have included with a specific type of PEP Event. like to have included with a specific type of PEP Event.
PEP Events provide a convenient means for the PEP to signal an event PEP Events provide a convenient means for the PEP to signal an event
that requires specific actions. A PDP authorization for access to that requires specific actions. A PDP authorization for access to
specific resources (and the potential verification of identity) is specific resources (and the potential verification of identity) is
one example of an event that not only requires a response but also one example of an event that not only requires a response but also
some potential provisioning work. It is interesting to note how some potential provisioning work. It is interesting to note how
neatly RSVP decision support fits into this model. In the original neatly RSVP decision support fits into this model. In the original
COPS design [COPS], the RESV request was sent in a COPS request and COPS design [COPS], the RESV request was sent in a COPS request and
a COPS response message determined whether the reservation should be a COPS response message determined whether the reservation should be
accepted or not. The enhancements provided by this PIB not only accepted or not. The enhancements provided by this PIB not only
allow RSVP messages to generate access requests, but also explicitly allow RSVP messages to generate PEP events (also called access
provision QoS resources, using COPS-PR [COPSPR], to support the requests), but also explicitly provision QoS resources, using COPS-
reservation. This generalizes COPS for RSVP and allows it to evolve PR [COPSPR], to support the reservation. This generalizes COPS for
to the COPS-PR model. RSVP and allows it to evolve to the COPS-PR model.
There are a number of situations where Events and associated There are a number of situations where Events and associated
provisioning need to be negotiated quickly. Mobile-IP applications provisioning need to be negotiated quickly. Mobile-IP applications
in particular require speedy resolution of PEP Events. This implies in particular require speedy resolution of PEP Events. This implies
that the combination of PEP Events 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).
2. Paradigm for the Bind PIB 2. Paradigm for the Access 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 events, known as ability to provisioning for future authorization events, known as
PEP Events. Second, there is a set of tables that used to notify the PEP Events. Second, there is a set of tables that are used to notify
PDP of an attempt to access managed resources. These tables can also the PDP of an attempt to access managed resources. These tables can
include credentials necessary to verify client identity. Finally, also include credentials necessary to verify client identity.
there are tables that determine how dialogs (COPS Request Handles) Finally, there are tables that determine how dialogs (COPS Request
between the PEP and PDP should be grouped. In order to provide Handles) between the PEP and PDP should be grouped. In order to
concurrency between competing events and provisioning requests, provide concurrency between competing events and provisioning
there must be a means for determining which PEP Events require a new requests, there must be a means for determining which PEP Events
COPS Request Handle and which should use existing handles. require a new COPS Request Handle and which should use existing
handles.
2.1 Event Handler Concepts 2.1. Event Handler Concepts
This section introduces the concept of an Event Handler. Much of This section introduces the concept of an Event Handler. Much of
what is described in this paper is based on the Event Handler. what is described in this paper is based on the Event Handler.
Event Handlers are implemented in PEPs and configured by PDPs. Event Event Handlers are implemented in PEPs and configured by PDPs. Event
Handlers are provisioned by standard COPS-PR protocol sequences. A Handlers are provisioned by standard COPS-PR protocol sequences. A
PEP will announce what Event Handlers are available in the PEP will announce what Event Handlers are available in the
capabilities table of the COPS-PR Request message. The PDP will capabilities table of the COPS-PR Request message. The PDP will
provision the Event Handlers with Decision messages. provision the Event Handlers with Decision messages.
Once an Event Handler is provisioned it is responsible for Once an Event Handler is provisioned it is responsible for
identifying packets that require the PDP to be notified with an identifying packets or API requests that require the PDP to be
Event Message. notified with an Event Message.
The general model for Event Messages requests includes a client, a The general model for Event Message requests includes a client, a
Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). In Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). In
this model, the PEP is the interface to the client, and the Event this model, the PEP is the interface to the client, and the Event
Handler is the part of the PEP that is responsible for recognizing Handler is the part of the PEP that is responsible for recognizing
the conditions for client authorization, generating the Event the conditions for client authorization, generating the Event
Message to the PDP, and communicating with the Client, if necessary, Message to the PDP, and communicating with the Client, if necessary,
to get identity or other information. to get identity or other information.
The Event Handler 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 Event Message to send to the PDP. It takes the translates it into an Event Message to send to the PDP. It takes the
provisioning Decision from the PDP and, in cases where the client is provisioning Decision from the PDP and, in cases where the client is
skipping to change at page 7, line 20 skipping to change at line 314
intermediate messages to authenticate the client prior to intermediate messages to authenticate the client prior to
provisioning the PEP with the policies appropriate to the client. provisioning the PEP with the policies appropriate to the client.
The PEP then returns a Report to the PDP confirming what was The PEP then returns a Report to the PDP confirming what was
provisioned by the Decision. provisioned by the Decision.
| C |->Access Request->| | | | | C |->Access Request->| | | |
| L | | |-Event Message---------->| | | L | | |-Event Message---------->| |
| I | <-(optional)-> |PEP | <-(optional)-> |PDP | | I | <-(optional)-> |PEP | <-(optional)-> |PDP |
| E | | |<-Provisioning Decision -| | | E | | |<-Provisioning Decision -| |
| N |<-Access Decision-| | | | | N |<-Access Decision-| | | |
| T | | | --> Access Report ----->| | |__T_| |____| --> Access Report ----->|____|
Fig. 2.1 Access Control Protocol Sequence Figure 2.1: Access Control Protocol Sequence
This paper is primarily concerned with the function of the Event This paper is primarily concerned with the function of the Event
Handler and the communication between the PEP and PDP. Communication Handler and the communication between the PEP and PDP. Communication
between the Client and PEP is assumed to be something like PPP or between the Client and PEP is assumed to be something like PPP or
802.1, and the capabilities described here should work with any 802.1, and the capabilities described here should work with any
Client/PEP communication method. Client/PEP communication method.
The PEP Event Message and PDP Provisioning Decision sequence is The PEP Event Message and PDP Provisioning Decision sequence is
similar to the "classical" COPS RSVP model. The Report confirming similar to the _classical_ COPS RSVP model. The Report confirming
that the Decision was installed correctly on the PEP is an extra that the Decision was installed correctly on the PEP is an extra
message beyond what is included in the RSVP sequence. We believe message beyond what is included in the RSVP sequence. We believe
this is a good approach, but expect further discussion (It is this is a good approach, but expect further discussion (It is
interesting to note that RADIUS does not send an acknowledgements of interesting to note that RADIUS does not send an acknowledgement of
Access Accepts/Rejects, and the DIAMETER drafts specify no Access Accepts/Rejects, and the DIAMETER drafts specify no
acknowledgement, but do expect a negative message if the Reply acknowledgement, but do expect a negative message if the Reply
cannot be processed correctly). cannot be processed correctly).
An Event Handler is a data path element in the PEP. Each Event An Event Handler is a data path element in the PEP. Each Event
Handler has a "selector" that identifies packets that should cause Handler has a _selector_ that identifies packets that should cause
Event Messages (See section 4.3 - Filter Entries). The selector Event Messages (See section 3.1.2). The selector essentially divides
essentially divides all packets into two sets, one set the Event all packets into two categories, in the first, the Event Handler is
Handler is responsible for generating Event Messages; the other set responsible for generating Event Messages; in the other, it just
it just passes to the next data path element. For example, if an passes the packets to the next data path element. For example, if an
Event HandlerÆs selector is "All new source IP addresses", an Event Handler's selector is _All new source IP addresses_, an
incoming packetÆs Source IP address is examined and if it is old, incoming packet's Source IP address is examined and if it is old,
the packet passed on without further processing. If the source IP the packet is passed on to the next data path element without
address is new or unknown, an Event Message is generated. further processing. If the source IP address is new or unknown, an
Event Message is generated and this packet may follow a different
sequence of data path elements.
Event Messages are grouped by COPS Request Handles. Each Event Event Messages are grouped by COPS Request Handles. Each Event
Message may cause a new COPS Request Handle to be generated or a set Message may cause a new COPS Request Handle to be generated or a set
of Event Messages may all share the same COPS Request Handle (note: of Event Messages may all share the same COPS Request Handle. The
see section 4.3-4.6). The distinction between selector and Event distinction between selector and Request Handle is spelled out in
Handle spelled out in 4.3-4.6, and will be worked on in the next section 3.1.4.4). Attributes in the Access Bind PIB are provided to
revision of this draft). Attributes in the Access Bind PIB are identify which COPS Request Handle a given Event Message should use.
provided to identify what how Event Messages are bound to COPS
Request Handles.
Event Handlers are designed to detect conditions in the PEP that Event Handlers are designed to detect conditions in the PEP that
result in the sending of Event Messages to the PDP. The Access Bind result in the sending of Event Messages to the PDP. The Access Bind
PIB defines a class to specify the criteria for generating an event. PIB defines a class to specify the criteria for generating an event.
In some cases an event is appropriate every time the criteria is In some cases an event is appropriate every time the criteria is
met. In other instances an event is appropriate only on the first met. In other instances an event is appropriate only on the first
occurrence. The provisioning event criteria can be difficult since occurrence. The provisioning of the event criteria using traditional
it is often the case that the PDP canÆt anticipate what the PEP will classifiers can be difficult since it is often the case that the PDP
see. For instance, when it is desirable to generate events every can't anticipate what the PEP will see. For instance, when it is
time a new user or device is recognized, the PDP canÆt anticipate desirable to generate events every time a new user or device is
which devices will be recognized or the order in which they will recognized, the PDP can't anticipate which devices will be
occur. Filter expressions can be constructed that enable the recognized or the order in which they will occur. Filter expressions
description of a set of packet fields that must match and a set of can be constructed that enable the description of a set of packet
packet fields that collectively represent a new, unique combination. fields that must match and a set of packet fields that collectively
This expressive capability allows the PDP to indicate to the PEP represent a new, unique combination. The expressive capability of
that one event should be generated the first time a Src IP address the Access Bind PIB allows the PDP to indicate to the PEP that one
has been seen by the PEP, but not generate events for subsequent event should be generated the first time a Src IP address has been
packets with the same Src IP address. seen by the PEP, but not generate events for subsequent packets with
the same Src IP address.
One interesting problem associated with event driven provisioning is One interesting problem associated with event driven provisioning is
avoiding blocking of one event due to provisioning activity for a avoiding blocking of one event due to provisioning activity for a
different event. On the other hand, there are situations where different event. On the other hand, there are situations where
serialization or ordering of events is important. We use COPS serialization or ordering of events is important. We use COPS
Request Handles to address both these needs. However, this requires Request Handles to address both these needs. However, this requires
explicit provisioning to indicate when new handles should be explicit provisioning to indicate when new handles should be
provisioned and which events should be processed through which provisioned and which events should be processed through which
handles. The approach taken in this paper is that the scope of the 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 COPS Request Handle is defined by one or more Filter entries. Some
in the COPS Framework PIB [FWPIB], this PIB and other PIBs. For of the filters are defined in the COPS Framework PIB [FWPIB] as well
example, if a FilterEntry object specifies SRC IP address as PIB modules defined in this document. For example, if a Filter
(10.20.0.0) and SRC IP Mask (FF.FF.0.0) each new IP address within object specifies SRC IP address (10.20.0.0) and SRC IP Mask
the range 10.20.0.0 and 10.20.255.255 will trigger the creation of a (FF.FF.0.0) each new IP address within the range 10.20.0.0 and
new Handle. The for this example, any packet with a SRC IP address 10.20.255.255 will trigger the creation of a new Handle. For this
that generates a new Event Message will use the existing handle if example, any packet with a SRC IP address that generates a new Event
that handle was already defined for that specific SRC IP address. Message will use the existing handle if that handle was already
defined for that specific SRC IP address.
When a packet arrives at the Event Handler, it first checks if it When a packet arrives at the Event Handler, it first checks if it
meets the criteria for generating an Event (event criteria will be meets the criteria for generating an Event (event criteria will be
discussed later). In the example above, a packet with a SRC IP 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 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 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 check is made to see if it matches the criteria for an existing COPS
Request Handle. Request Handle.
If it does not match the criteria for an existing COPS Request If it does not match the criteria for an existing COPS Request
Handle, then the PEP instantiates a new Request Handle and sends an Handle, then the PEP instantiates a new Request Handle and sends an
Event Message to the PDP using the new Handle. In either case the Event Message to the PDP using the new Handle. In either case the
PDP analyzes the Event Message, possibly sending additional messages PDP analyzes the Event Message, possibly sending additional messages
back to the PEP to support authentication and provisioning for the back to the PEP to support authentication and provisioning for the
new address. If authentication was performed, a final Authentication new address. If authentication was performed, a final Authentication
Result object is sent to the PEP to indicate the authentication was 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 successful or not. This is needed to allow the PAP, CHAP and EAP
authentication processes to report success back to the authentication processes to report success back to the
authenticating user. 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 a classifier that has In the example, the PEP is configured with a classifier that has
explicit entries for each source address that has already be explicit entries for each source address that has already been
authenticated and a default classifier element matching all addresses authenticated and a default classifier element matching all addresses
to points to an Event Handler. Since the default classifier element that has an Event Handler as the next element. Since the default
is only used if none of the other classifier elements match, the classifier element is only used if none of the other classifier
Event Handler is only invoked for new Src IP addresses that have not elements match, the Event Handler is only invoked for new Src IP
yet been explicitly provisioned into the classifier. Each non-default addresses that have not yet been explicitly provisioned into the
classifier element points to another classifier that lists the classifier. Each non-default classifier element points to another
policies uniquely for that Src IP address. The addresses of "premium" classifier that lists the policies uniquely for that Src IP address.
users are assigned a high QoS while the addresses of "normal" users The addresses of _premium_ users are assigned a high QoS while the
are assigned best effort QoS. Since the Event Handler is not addresses of _normal_ users are assigned best effort QoS. Since the
terminating any packets, the Event Handler passes all packets through Event Handler is not terminating any packets, the Event Handler
to the Best Effort Queue. passes all packets through to the Best Effort Queue.
When the PEP comes up it sends information about its Event Handlers When the PEP comes up it sends information about its Event Handlers
to the PDP in a capabilities table. After capability negotiation is to the PDP in a capabilities table. After capability negotiation is
complete, the PDP provisions a set of policies that configure the complete, the PDP provisions a set of policies that configure the
Event Handlers behind the Ethernet interfaceÆs datapath. Each Event Event Handlers behind the Ethernet interface's data path. Each Event
Handler Table will have a pointer to a (tagged) set of Handler Table will have a pointer to a (tagged) set of
EventHandlerElement Tables that provide Filter matching and COPS EventHandlerElement Tables that provide Filter matching and COPS
Request Handle matching rules. In this case, the EventHandlerElement Request Handle matching rules. In this case, the EventHandlerElement
table will be provisioned generate unique Request Handles and Events table will be provisioned to generate unique Request Handles and
the first time it matches a new "SourceIPAddresses." Events the first time it matches a new _SourceIPAddress._
Once the Event Handler is setup, it is able to process packets Once the Event Handler is setup, it is able to process packets
arriving at the Ethernet Interface. The Event Handler looks at all arriving at the Ethernet Interface. The Event Handler looks at all
packets with Src IP addresses that have not been explicitly been packets with Src IP addresses that have not been explicitly been
defined in the upstream Classifier and uses the event matching rules defined in the upstream Classifier and uses the event matching rules
to check if the packet contains an unknown Src IP address within the to check if the packet contains an unknown Src IP address within the
configured range. If the packet matches an event matching rule, the configured range. If the packet matches an event matching rule, the
Event Handler checks what information the PDP requires from the Event Handler checks what information the PDP requires from the
Client (e.g. username and credential), and collects this Client (e.g. username and credential), and collects this
information. The PEP then checks to see if it should use an existing information. The PEP then checks to see if it should use an existing
skipping to change at page 10, line 12 skipping to change at line 464
managed through a single COPS dialog. A unique handle also has the managed through a single COPS dialog. A unique handle also has the
benefit of automatically removing all objects provisioned through benefit of automatically removing all objects provisioned through
the Handle when the Handle is deleted (the user ends their session). 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 After the Request Handle is set up, an Event Message is sent to the
PDP containing the user information including address, port, and PDP containing the user information including address, port, and
credential information. credential information.
The PDP checks the information passed in the Event Message, The PDP checks the information passed in the Event Message,
authenticates the client (if required), and decides which policy authenticates the client (if required), and decides which policy
should apply to that IP address. It sends a Provisioning Decision, should apply to that IP address. It sends a Provisioning Decision,
containing the appropriate policy (assign to "premium" queue) to the containing the appropriate policy (add classifier element for the
PEP using the newly created Request Handle. new address and set the next element of the classifier element to
the _premium_ queue) to the PEP using the newly created Request
Handle.
Additional examples using the Access Bind PIB to support RSVP, Additional examples using the Access Bind PIB to support RSVP,
802.11, and other protocols are described in section 7. 802.11, and other protocols are described in section 8.
2.2. Context Data 2.1.2. Context Data
As mentioned previously, Event Messages 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 provide enough information to the PDP to provide proper to provide enough information to the PDP to provide proper
provisioning guidance. Therefore a mechanism is required that allows provisioning guidance. Therefore a mechanism is required that allows
the PDP to specify what information is needed. 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 MPLS label stacking). The
class, described in more detail below, allows the PDP to explicitly ContextData class, described in more detail below, allows the PDP to
specify the set of nested headers that it needs more details on. explicitly specify the set of nested headers that it needs more
This can either be specified in from the outermost header or the details on. This can either be specified in from the outermost
innermost header, as well as all headers of a particular type. header or the 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
and interface specific, it is appropriate to organize the device 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
difficult to adapt to new types of information. The second difficult to adapt to new types of information. The second
alternative is very configuration intensive, particularly for header alternative is very configuration intensive, particularly for header
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.9. The messages used to send discussed in more detail in sections 3.1.3 and 3.1.4.5. The messages
ContextData are discussed in sections 5.1, 5.2, 5.3, and 6.1. used to send ContextData are discussed in section 7
2.3. Policy Distribution and Management 2.1.3. Policy Distribution and Management
One of the purposes of this paper is to demonstrate how One of the purposes of this paper is to demonstrate how
authorization and authentication can be bound to traditional COPS authorization and authentication can be bound to traditional COPS
provisioning. Stated somewhat differently, this paper provides the provisioning. Stated somewhat differently, this paper provides the
means for seamlessly integrating outsourcing with provisioning using means for seamlessly integrating outsourcing with provisioning using
only PIBs. Authorization, Authentication, and COPS/RSVP are all only PIBs. Authorization, Authentication, and COPS/RSVP are all
forms of outsourcing because they are all triggered by events in the forms of outsourcing because they are all triggered by events in the
PEP and depend on decision support from the PDP. Earlier sections PEP and depend on decision support from the PDP. Earlier sections
have gone into fair detail in describing how the PEP can generate have gone into fair detail in describing how the PEP can generate
Event Messages. 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 Event Handlers themselves. Section First is the provisioning of the Event Handlers themselves. Section
2.1 went into some detail describing how Event Handlers are 2.1 went into some detail describing how Event Handlers are
provisioned using policy decisions. More details on the Event provisioned using policy decisions. More details on the Event
Handler tables can be found in sections 4.1, 4.2, and 4.3. In Handler tables can be found in sections 3.1.1 and 3.1.4. In addition
addition the provisioning messages used to configure Event Handlers the provisioning messages used to configure Event Handlers are also
are also described in section 5.1. described in section 7.1.
The second aspect of provisioning is the use standard provisioning The second aspect of provisioning is the use of standard
decisions to bind policies to authorized clients. The goal in provisioning decisions to bind policies to authorized clients. The
binding events to policies was to minimize reconfiguration. goal in binding events to policies was to minimize reconfiguration.
Therefore, this PIB has been designed to provision Event Handlers as
well as Policies once and bind them together dynamically.
The process for this binding is as follows. An Event Handler can be The process for this binding is as follows. An Event Handler can be
configured to generate COPS Request Handles and trigger an Event configured to generate COPS Request Handles and trigger an Event
Message based on specific criteria. These criteria explicitly scope Message based on specific criteria. These criteria explicitly scope
the Request Handle. For example, if the criteria were one per unique the Request Handle. For example, if the criteria were one per unique
source IP address, then there would be one Request Handle for each source IP address, then there would be one Request Handle for each
unique source IP address and all policies bound to through that unique source IP address and all policies bound to that Request
Request Handle would typically operate on all traffic with that Handle would typically operate on all traffic with that source IP
source IP address. Note that the criteria that scope a Request address. Note that the criteria that scope a Request Handle could
Handle could also be a unique protocol, unique VLAN, or each unique also be a unique protocol, unique VLAN, or each unique RSVP RESV
RSVP RESV message. It is also worth noting that the Request Handle message. It is also worth noting that the Request Handle bounding
bounding criteria could also be a unique combination of field values criteria could also be a unique combination of field values such as
such as a VLAN and TCP Port Number. a VLAN and TCP Port Number.
With the scope of a Handle specified, the Event Handler can With the scope of a Handle specified, the Event Handler can
instantiate new Handles in conjunction with the Event Message. instantiate new Handles in conjunction with the Event Message.
2.4. Interactions with DiffServ model This PIB has been designed to provision Event Handlers as well as
Policies once and bind them together dynamically. As described
above, each Request Handle can manage a set of policies. However, in
most cases, these policies reference data path elements that are
shared by multiple Handles. For example, a new IP address may
generate a unique Request Handle that in turn provisions one or more
elements in the Classifier table. However, these elements may in
turn point to other data path elements, such as queues or meters
that are shared across multiple independent IP address classifier
elements.
2.2. Event Handlers and Application-Specific PIBs
The Access Bind PIB is actually a modular set of PIBs. The Common
PIB contains the Event Handler and it's associated structures. An
extension PIB is also provided to support user authentication. This
PIB is provided because only a subset of Events require identity
management. Other PIBS are included in this document to support a
variety of applications. In the future, these PIBS may be specified
in independent documents. The Application-Specific PIBs minimize the
number of COPS-PR classes that must be implemented in order to
support Event Handler functionality for the many applications that
require policy outsourcing.
2.3. Passive Monitoring vs. Programmatic API
The Event Handler is designed to operate in two specific scenarios.
The first is a passive monitoring environment. In this mode, the
Event Handler can be provisioned to detect specific types of traffic
and generate events to the PDP based on the traffic. The Event
Handler does not alter the packets in any way. However, packets may
be sent to different packet processing engines depending on the
decisions the PDP installs after responding to the event. The
Passive Monitoring mode was designed to operate within the context
of the DiffServ data path model. This model is discussed in more
detail in Section 2.3.1.
In the second scenario, no packets are analyzed because some
intermediate system is processing the packets and generating events.
In this mode, the system needs the help of the PDP to continue
processing. Therefore, the system uses a signaling API to interact
with the Event Handler, which in turn generates the events and
receives the decisions. This mode is particularly useful for RSVP.
Since the RSVP engine is processing the actual PATH and RESV
messages, there are no packets for the Event Handler to process or
analyze. In fact, the traditional COPS model defines a mapping of
the RSVP policy engine to COPS messages. The Access Bind PIB is
constructed to support a programmatic interface to the Event
Handler. Further, the Programmatic API uses the same mechanisms as
the passive monitoring mode to configure new policies in
intermediate systems. For instance, a RESV event received by the
Event Handler through the programmatic interface and propagated to
the PDP allows the PDP to generate data path decisions that can be
installed in the intermediate system through the programmatic API.
The concepts behind this model are discussed in greater depth in
Section 2.3.2.
It is worth noting that both these modes are abstractions that may
be equally applicable. It is possible to represent a service using
the data path model and it is possible to represent a packet
processing engine as a service with a programmatic interface to the
PEP. It is a design decision that dictates the preferred approach
for processing PEP events. The advantage of the passive monitoring
approach is that it can more accurately represent the behavior of
the system. However the API is more tolerant in the areas of filter
definition and COPS request handle management.
2.3.1. Interactions with DiffServ data path 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. The Event Handler is addition of new Data Path Functional Elements. The Event Handler is
one such new Data Path Functional Element. Previous sections have one such new Data Path Functional Element. Previous sections have
already described how this PIB extends the existing DiffServ already described how this PIB extends the existing DiffServ
Informal Model and the DiffServ PIB. However, it is worth describing Informal Model and the DiffServ PIB. However, it is worth describing
how this PIB enhances the basic DiffServ model. First and foremost, how this PIB enhances the basic DiffServ model. First and foremost,
this new PIB provides a means for scaling the basic DiffServ model this new PIB provides a means for scaling the basic DiffServ model
to the edges of the network that can have many interfaces and many to the edges of the network that can have many interfaces and many
specialized services. Previous PIBs only supported the static specialized services. Previous PIBs only supported the static
configuration of data paths. This meant that dynamic events such as configuration of data paths. This meant that dynamic events such as
binding of new clients to existing or new services were difficult to binding of new clients to existing or new services were difficult to
support because there was no way to anticipate new clients and support because there was no way to anticipate new clients. In
because most provisioning was managing classifiers on a per client addition most provisioning was managing Classifiers on a per client
per service basis did not scale well. per service basis, which scales geometrically as the number of
clients and services increases.
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 dynamic (event driven) semantics but separating the creation of dynamic (event driven)
policies into a new data path component. This provides a stable data policies into a new data path component. This provides a stable data
path for the generation of authorizations while also supporting a path for the generation of authorizations while also supporting a
stable data path for the services that various clients may make use stable data path for the services that various clients may make use
of. The linchpin of this PIB is the Event Handler that provides a of. The linchpin of this PIB is the Event Handler, a new type of
new type of demultiplexor that separates streams of traffic into demultiplexor, that separates streams of traffic into individually
individually grouped triggers that in turn support dynamic grouped triggers that in turn support dynamic authorization. The
authorization. The policy provisioning that results from these policy provisioning that results from these events can be bound back
events can be bound back to pre-defined policies to minimize the to pre-defined policies to minimize the changes required to support
changes required to support new clients. As a result, with this PIB, new clients. As a result, with these PIB modules, service policies
modifications to service policies can be added or removed at the can be added or removed at the session level rather than the raw
session level rather than the raw data path level. data path level.
So far we have only discussed the value of authorizing a client when So far we have only discussed the value of authorizing a client when
the link notices new IP address. However, it is worth noting that the link notices a new IP address. However, it is worth noting that
because the Event Handler is part of the data path definition, it is because the Event Handler 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 Event Handler can be placed
behind a Classifier to explicitly authorize access to a specific behind a Classifier to explicitly authorize access to a specific
part of the network or specific services. The Event Handler can also part of the network or specific services. The Event Handler can also
be the FailNext element behind a meter resulting in an authorization be the FailNext element behind a meter resulting in an authorization
for the use of out-of-profile traffic. Bandwidth Brokers can use for the use of out-of-profile traffic. Bandwidth Brokers can use
this approach or an Event Handler trapping RSVP RESV messages to this approach or an Event Handler trapping RSVP RESV messages to
support dynamic bandwidth allocation decisions. support dynamic bandwidth allocation decisions. MPLS LSRs and LERs
can use this to detect label path addition or modification events.
The integration of Event Handler as a Data Path Functional Element The integration of Event Handler as a Data Path Functional Element
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 the Event functionality at the edge of the network with usage of the Event
Handler. This can now be totally controlled via the use of COPS-PR. Handler.
The Policy Server level interaction with DiffServ comes naturally The Policy Server level interaction with DiffServ comes naturally
with the integration of Event Handler as a Data Path Functional with the integration of Event Handler as a Data Path Functional
Element 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 Event Handler becoming appropriately in the schema level, with the Event Handler becoming
stimuli for DiffServ provisioning. stimuli for DiffServ provisioning.
2.5. Interactions with RSVP model 2.3.2. The Programmatic API to the Access Bind PIB
The Event Handler model provides a means for detecting RSVP RESV
messages. This means that the traditional COPS outsourcing model
could eventually be phased out in favor of the provisioning model
and the use of this PIB. This is discussed in more detail in section
7.2.
3. Supporting various client Authentication Protocols
In the operational model for this PIB, the Authentication Server is
a specific function of the PDP. The main purpose of the
authentication portions of this PIB is to verify the validity of
client credentials by an Authentication Server. The verification
process itself may do this whilst ensuring some level of
authenticity, confidentiality and integrity. Messages exchanged
between a Client and Authentication Server (PDP) may remain
confidential to PEP's and Proxy Servers. The message integrity may
be ensured by some hashing algorithm so PEP's and Proxy's may
inspect but not modify the content of authentication messages.
Clients, PEP's, Proxy's and PDP's will always need some security
method to ensure message authenticity.
Some authentication protocols explicitly consider proxies by
allowing the payload to be carried over a variety of transports.
Others depend on the termination point of the connection to
explicitly proxy the authentication, when that is necessary. In
order to demonstrate the general utility of this model, a variety of
client authentication protocols will be considered in this document.
For each protocol, the negotiation mechanism will be described and
the mapping to this framework will be detailed.
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
authentication protocols is that EAP assumes the negotiation is
between the client and the authentication server. In anticipation of
the fact that the terminating point of a connection such as PPP or
L2TP is not necessarily the same as the agent managing client
authentication, EAP encapsulates itÆs negotiation process in a
separate header that can be forwarded in entirety to the server.
This mechanism provides extra security by preventing intermediate
proxies from monitoring or managing authentication credentials.
EAP supports a number of different authentication mechanisms
including MD5, TLS, and One-Time-Password authentication.
The terminology used in [EAP] differs from the terminology used in
this document. In particular, the peer, as defined in section 1.2 of
[EAP], is referred to as "Client" in this document. Similarly, the
"authenticator" is called a PEP in this document and "back-end
server" is called the Authentication Server function of the PDP (or
just PDP) in this document.
3.2.1. EAP Message sequence
The generic sequence of transmissions between the PEP and PDP has
already been described in section 2. In particular, figure 2.1 gives
an overview of the messages involved between the Client workstation,
PEP and PDP. EAP messages are embedded in PPP packets in the
communication between the Client and the PEP. In the communication
between the PEP and PDP, the EAP messages are embedded in COPS
Request, COPS Decision and COPS Report messages. Figure 3.1 shows
how EAP may be used to retrieve credentials from the client
workstation by the PDP.
time
| +---+ +---+ +---+
| | | | |-- COPS-PRC exchange ---->| |
| | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-EAP --| | | |
| | U |-- PPP LCP ACK-EAP ->| P | | P |
| | s |<- PPP EAP Req Id ---| E | | D |
| | e |-- PPP EAP Res Id -->| P | | P |
| | r | | |-- COPS-Req Ses-EAP ---->| |
| | | | |<- COPS-Dec EAP Req Chal -| |
| | |<- PPP EAP Req Chal -| | | |
| | |- PPP EAP Res Chal ->| | | |
| | | | |- COPS-Rep EAP Res Chal ->| |
| | | | | | |
| | | | |<- COPS-Dec EAP Success --| |
| | |<- PPP EAP success --| | | |
V +---+ +---+ +---+
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
opaque to the PEP.
Typically, when the PEP boots up, it sends itÆs capabilities to the
PDP in a COPS message and is than configured by the PDP with one or
more datapathEventHandlers specifying the criteria for generating
PEP Event Messages. The first message after this provisioning
process from the PEP to the PDP is a new Event Message. The PEP
sends a COPS request to 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 EAP 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 of which Filter (by means of the
eventhdlrEventScope) triggered the event.
All EAP messages necessary to complete the authentication process
will be forwarded to the PDP. All of the negotiation occurs between
the Client and the PDP and should, except for the EAP message code
field, not be examined by the PEP. In order to support multiple EAP
protocols, this PIB supports a generic EAP request class and EAP
response class. Each class has a single string attribute
(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
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 may continue to retrieve additional credentials from the client
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
PEP with policies. This is action is not shown in figure 3.1.
The PDP should end the EAP negotiation with an EAP Success or an EAP
Failure message. If the PDP sends a EAP Success, the PEP must from
then on use the matchNext Prid to determine the next processing
filter for data defined by the values described using the
eventhdlrEventScope.
3.2.2. AuthEapReqExt and AuthEapRespExt data structures
The EAP messages are embedded in COPS by sending an instance of the
authEapReqExt or authEapRespExt table, which each have an attribute
(Specific) to encapsulate the appropriate EAP messages necessary for
the authentication mechanism. 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
instances that it sends in Decision messages and the PEP generates
authEapRespExt instances that it sends in Report messages. Since
neither the PEP nor the PDP needs to maintain the messages
permanently, the same instance of each class is used when more than
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
------------------------------- --------------
authExtId InstanceId
authExtEvent ReferenceId
authEapReXXExtSpecific OCTET STRING
Fig 3.2: Data elements in AuthEapReqExt and AuthEapRespExt tables
The AuthEapReXXExt class contains three attributes. The instanceId
is used to uniquely define the instance in the table. However, since
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
message is transient instances of these tables are temporary and
should not be referred to. The Event attribute points to the Event
table entry for which EAP is being negotiated. The format of EAP
packages being passed by the AuthEapReXXExt classes is described in
[EAP].
3.3. PAP Authentication
PAP (Password Authentication Protocol), as described in section 2 of
[AUTH] is a very simple authentication mechanism used over PPP. It
is not considered to be a secure mechanism, since it sends passwords
over the wire in clear text format. However, where one-time
passwords are used, this security concern is mitigated. It is
described here nonetheless for illustration purposes and because it
may still be used among ISPs, or in situations where another layer
already performs encryption for security.
The terminology used in [AUTH] differs from the terminology used in
this document. In particular, the peer as defined in section 1.2 of
[AUTH] is referred to as "Client" in this document. Similar, the
"authenticator" is called PEP in this document.
3.3.1. PAP Connection sequence
Figure 3.3 shows how PAP may be used to retrieve credentials from
the client workstation by the PDP.
time
| +---+ +---+ +---+
| | | | |-- COPS-PRC exchange ---->| |
| | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-PAP --| | | |
| | U |-- PPP LCP ACK-PAP ->| P | | P |
| | s |-- PPP PAP Id, Pwd ->| E | | D |
| | e | | P |-- COPS-Req event, -->| P |
| | r | | |-- userPapExt -->| |
| | | | | | |
| | | | |<- COPS-Dec eventElement -| |
| | | | |<- COPS-Dec authResult ---| |
| | |<- PPP PAP ack ------| | | |
V +---+ +---+ +---+
Fig 3.3: Embedding of PAP messages between the Client workstation
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
will embed the password into the userPapExt datastructure and send
this to the PDP. Since this datastructure inherits the fields of the
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 an alert that an
event was triggered. The PEP sends an Event Message over COPS to 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.
Besides these required instances, the PEP might have been configured
by the PDP to sent 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 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.
3.3.2. AuthPapExtEntry datastructure
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
--------------------------- --------------
authExtId InstanceId
authExtEvent ReferenceId
authRealm OCTET STRING
authUsername OCTET STRING
authPapExtPwd OCTET STRING
Fig 3.4: Attributes of the AuthPapExt table.
The AuthPapExt contains five attributes. The instanceId is used to
uniquely define the instance in the table. However, since the PAP
password is sent to the PDP once and is needed by neither the PDP
nor the PEP after the client is authenticated, the instance should
not be referenced after it is used the first time. The Event
attribute points to the Event table entry for which PAP is being
negotiated.
The result of the authentication for PAP is sent in the
AuthExtResult table. Since the authExtResult table is an extension
of the AuthExt table, it inherits the attributes of AuthExt.
AuthExtResult table attributes Attribute type The programmatic API to the Access Bind PIB is actually an
------------------------------ -------------- implementation specific abstraction that allows intermediate systems
authExtId InstanceId to interact with the Event Handler. This PIB only defines the
authExtEvent ReferenceId messages that enable the Event Handler to generate events on behalf
authExtAuthSuccess Truth Value of intermediate systems. Since implementations of intermediate
systems such as RSVP vary greatly both in features and usage, the
actual API that maps the RSVP policy engine to the Event Handler is
dependent on the actual outsourcing requirements of the intermediate
engine. However, the Access Bind PIB is extremely flexible and can
accommodate a broad range of events and policy decisions.
Fig 3.5: Attributes of the AuthExtResult table. The typical programmatic API will have interfaces (methods) that
parallel the sequence of messages seen in the data path mode of
operation. The intermediate system will first invoke the API to
register itself with the PDP. The COPS-PR side of the API would
generate a Capabilities message indicating that the device supports
the protocol or service represented by the intermediate system. The
functionality of the API will be described by using RSVP as an
example. It should be noted that any other service (such as SIP,
H.323, or 3GPP-go) that needs to outsource policy requests would
work the same way. In the case of RSVP, the API might be a function
like EventHdlrRegister(RSVP-type). The API would in turn generate a
COPS-PR capabilities message indicating that RSVP can be provisioned
and monitored through the event handler.
The AuthExtResult is sent by the PDP to the PEP. If the The next step is a response from the PDP that provisions a set of
authentication was successful and the PEP should from now on use the controls. The first is the provisioning of the Event Handler that
matchNext Prid to determine the next processing filter (the next will interact with RSVP via the API. When the Event Handler is
component down the internal datapath in the PEP) for all traffic provisioned, the RSVP service is notified that it may now outsource
defined by the values of the parameters as set in the RSVP reservation requests to the PDP through the API. Second, there
eventhdlrHandlerScope. may be several provisioning tasks that are configured in the RSVP
service through the API. In many implementations of RSVP there may
be many reservations requiring varying levels of QoS but only a few
Queues to support the scheduling of various RSVP flows. In these
situations the PDP may provision some or all of these queues using
the Framework [FWPIB] and DiffServ PIB [DSPIB]. The API can then be
used to map these provisioning requests to the actual RSVP
implementation within the RSVP service. This allows the pre-
configuration of queues, schedulers.
3.4. CHAP Authentication When a reservation is processed by the RSVP service, the API is used
to notify the event handler of a new RSVP event. When the event
handler is provisioned some of the provisioned structures specify
what events (RESV, PATH, etc.) the PDP will respond to and what
information must be included in an event message. The API may be
invoked with a method like EventGenReq() with parameters that
describe the type of message and the context data that the PDP
requires and the COPS request handle to use for this reservation.
CHAP (Challenge Authentication Protocol) [CHAP] is a strong When the PDP completes the processing of the event, a set of
authentication mechanism, which eliminates the need to send decisions are sent back to the PEP. These decisions are handed to
passwords in the clear, like PAP does. With CHAP, the Authenticator the RSVP service via the API. The decisions will determine how the
generates a challenge key, sends it to the Peer (Client) and the reservation is to be processed. If several queues were pre-
client responds with a cryptographically hashed response that provisioned, the decisions may provision a classifier matching the
depends upon the Challenge and a secret key. The PDP checks the reservation's flow (4-tuple) and a meter that rate limits the
secret key by performing the same encryption and comparing the traffic to the R-SPEC [RSVP]. The decisions would also indicate that
results. the classifier should have the meter as the next element and that
the meter would have the appropriate (pre-provisioned) queue as its
next element. The API may be implemented as a synchronous or
asynchronous interface. If the interface is synchronous, the API
will return an indication back to the event handler as to whether
the decisions were successfully installed or not. If the interface
is asynchronous, the API will call the event handler explicitly to
indicate success or failure. In either case, an explicit decision
result message must be sent back to the PDP so that both the PEP and
PDP are kept in sync on which policies have been installed in the
PEP.
The terminology used in [CHAP] differs from the terminology used in When the RSVP service determines that the reservation should be torn
this document. In particular, the peer as defined in section 1.2 of down, the API is used to close/terminate the COPS Request Handle.
[CHAP] is referred to as "Client" in this document. Similar, the This action will cause both the PEP and the PDP to remove the
"authenticator" is called PEP in this document. decisions associated with this reservation (the classifier and
meter).
3.4.1. CHAP Connection sequence 3. Access Bind PIB
Figure 3.6 shows how CHAP may be used to retrieve credentials from Figure 3.1 shows the basic operation of the Access Bind PIB. In the
the client workstation by the PDP. first phase, the Event Handler is provisioned in the PEP. This
process enables the PEP to trap the configured events and pass them
to the PDP. The process of trapping events may involve an
intermediate step of authenticating the user or device. This step is
represented in Figure 3.1 as an event message with possible
authentication message exchanges between the PDP and the
user/device. After the event (and optional authentication has been
processed by the PDP, the PDP can provision the PEP with a set of
policies specific to that user, device, or event. When the decision
policies are installed, the PEP notifies the PDP that the install
has succeeded or failed. In addition, if authentication was
involved, the user or device may be notified that the authentication
process has completed.
time time
| +---+ +---+ +---+ | +---+ +---+ +---+
| | | | |-- COPS-PRC exchange ---->| | | | | | |-- provisioning req. ->| |
| | | | |<- COPS-Dec eventHandler -| | | | | | |<-- provisioning ------| |
| | |-- PPP traffic ----->| | | | | | U |-- traffic ----------->| | | |
| | |<- PPP LCP Req-CHAP -| | | | | | s |<-- (authentication) ->| P | | P |
| | U |- PPP LCP ACK-CHAP ->| P | | P | | | e | | E |-- event (w/ authen) ->| D |
| | s |<- PPP CHAP Chal ----| E | | D | | | r |<-- (authentication) --+ P +-- (authentication) -->| P |
| | e |-- PPP CHAP Ident, ->| P | | P | | | | | |<-- decision ----------| |
| | r |-- Id, Resp ->| | | | | | |<-- decision ----------| |-- decision success -->| |
| | | | |-- COPS-Req event-CHAP -->| |
| | | | |-- COPS-Rep CHAP Resp, -->| |
| | | | |-- Chal -->| |
| | | | | | |
| | | | |<- COPS-Dec eventElement -| |
| | | | |<- COPS-Dec authResult ---| |
| | |<- PPP CHAP ack -----| | | |
V +---+ +---+ +---+ V +---+ +---+ +---+
Fig 3.6: Embedding of CHAP messages between the Client workstation Figure 3.1: Typical message sequence when a trigger occurs.
and the PEP, and between the PEP and PDP.
As soon as the PEP finished negotiating CHAP as the Authentication In many scenarios, no identity management will be required and the
protocol, it generates a challenge itself, and sends this to the authentication steps will not occur. This is why identity management
Client. The client will respond to this authentication request by classes have been place in a separate PIB, which is discussed in
sending his or her identity, an identifier and the response. The more detail in Section 4.
response is a cryptographically encrypted hash based on the
challenge and secret key (password).
The identifier is only used to keep track of CHAP messages, and Section 3.1 will describe how the PDP installs an event handler into
needs to be used by the PEP to recover the associated challenge. a PEP, and when the PEP should trigger an event. Section 3.2, about
the event handling, will describe the actions that the PEP needs to
perform when an action is triggered. This chapter will focus on
generic event handlers; Section 5 will describe additional classes
required to support event handlers within the context of specific
signaling applications. Chapter 7 will describe the message sequence
that follows the event request, as well as the message sequence
associated with identity authentication.
The first connection from the PEP to the PDP is a notice of a new 3.1. The Event Handler
Event. The PEP sends an Event Message to 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 CHAP
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 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.
Note that having the PEP issue the challenge allows the PEP to This Section will describe the concept of Events, Event Handlers,
perpetrate fraud by issuing a replayed request (assuming that the Event Handler Element, Event Handler Event Scopes, and Event Handler
PEP and PDP are in different domains). The only guard against this Handle Scopes.
is for the PDP to check that multiple authentication requests for
the same client have unique challenges. This may be slow. PDP and
Authentication server developers who feel this is a security issue
may want to use EAP-MD5 authentication rather then CHAP
authentication, since EAP-MD5 addresses this problem by letting the
PDP generate the challenge.
Besides these required instances, the PEP might have been configured In the framework described in this document, only events that match
by the PDP to send additional information about the client to the a predefined set of criteria can be sent from the PEP to the PDP.
PDP. For example in the case of a dialup connection between the The main purpose of the Event Handler is to provision the PEP with
Client and the PEP, the PDP might specify using a contextData that set of criteria. If the criteria provisioned by the PEP are
instance that the PEP should also sent an instance of a met, the PEP must send an Event message to the PDP.
ctxtDialupInterface.
The PDP performs the CHAP authentication. When the authentication is 3.1.1. Functional Description
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 PDP provisions the event handler onto the PEP. However, the PEP
is the first machine to contact the PDP, typically at boot time of
the PEP. The PEP and the PDP communicate with each other using
common COPS-PR messages. After the PEP send a capability message
indicating that it supports event handlers, the PDP will respond by
provisioning the PEP with a set of configuration elements. These
elements may include one or more instances (PRIs) of the Event
Handler class, the EventHdlrElement class, the EventHdlrScope class
and optionally the ContextDataPointer class. The PEP will respond to
this configuration request with a common COPS-PR report message
indicating that these elements have been successfully provisioned.
The CHAP information is embedded in the Event Message by sending an | P |---- COPS-PR Capability message -->| P |
instance of the authChapExt table. Since the authChapExt table is an | E |<--- - COPS PR Decision -------------| D |
extension of the userAuthExt table, which is an extension of the | P |---- COPS-PR Report State -------->| P |
authExt table, the authChapExt table inherits the attributes of
these tables.
AuthChapExt table attributes Attribute type Figure 3.2: The PEP initialization sequence
---------------------------- --------------
authExtId InstanceId
authExtEvent ReferenceId
authRealm OCTET STRING
authUsername OCTET STRING
authChapExtId Unsigned32
authChapExtChal OCTET STRING
authChapExtResp OCTET STRING
Fig 3.7: Data elements of the AuthChapExtEntry datastructure. The COPS Decision message that the PDP sends to the PEP should
contain at least one EventHandler Instance. The EventHandler Entry
is the base object which defines the behavior of the PEP when no
event criteria are met. Each EventHandler is accompanied with one or
more EventHandlerElements. Each EventHandlerElement describes the
action which the PEP should take in case one of the event criteria
is met.
The AuthChapExtEntry contains seven attributes. The instanceId is The EventHandler and the set of EventHandlerElements are grouped
used to uniquely define the instance in the table. However, since together because each EventHandlerElement in the same group has the
the CHAP information is sent to the PDP once and is needed by same TagId in the eventHdlrElementGrpId attribute. The EventHandler
neither the PDP nor the PEP after the client is authenticated, the is associated with this group because it has the same value in the
instance should not be referenced after it is used the first time. eventHdlrElementGrpId attribute.
The Event attribute points to the Event table entry for which PAP is
being negotiated.
The authChapExtChal attribute is the challenge generated by the PEP. The EventHandlerElement objects specify what actions should be taken
The PDP may check the challenge to see if it is different from if an event is triggered. To specify when an event must be
challenges used earlier. This provides an increased level of triggered, the EventHandlerElement uses zero or more
security. The Response and the Id is taken from the CHAP message EventHdlrEventScopes. The Scopes are also grouped using a TagId, and
sent by the client and put into the AuthChapExtEntry by the PEP. have a precedence field. Each scope defines a simple condition, and
all scopes from one group together form a complex boolean expression
based on the eventHdlrEventScopePrecedence fields. If two scopes in
the same group have a different precedence number, then the event
criteria for the EventHandlerElement is met if one of the scopes
condition is met. If two scopes in the same group have the same
eventHdlrEventScopePrecedece fields, the event criteria are only met
if BOTH conditions of the EventHdlrElements are met.
3.5. HTTP Authentication Take for example, an EventHandlerElement with an
eventHdlrElementEventScope TagId (and thus the
eventHdlrEventScopeGroup TagReferenceId of a certain
group) set to 5, and there are 3 scopes in the group 5, with the
eventHdlrEventScopePrecedence set to 2, 3, and 3 respectively for
scope A, B and C. Then, only an event is triggered if (the criteria
of scope A OR (the criteria of scope B or the criteria of scope C))
are met. The exact rules are explained in section 3.2.4.
This section will be added in a subsequent version of this draft. 3.1.2. Event Criteria behavior
4. Data Structures One key aspect of the EventHdlrElement is the Event Criteria
attribute. This attribute is used to describe whether unique events
are one time events or repeatable events. For instance, every RSVP
message may need to result in an Event Message. However, an Event
Message may only be appropriate the first time a new Src IP address
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 3.2.2 for more details of the behavior of the 'On_Change'
attribute.
The data classes defined formally in the Authentication PIB module Whenever traffic arrives at the EventHandler for which an Event
(section 7) are introduced and discussed here. Message has not already been generated, it is compared against the
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.1. Event 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.
Instances of this table represent events that occurred at the PEP. When multiple fields are specified for the filter and the ChangeFlag
The events reference the event handler instance and the specific is set to 'True', each unique combination of field values generates
event handler element that the event was caught by. an event. For example, if the SRC IP is assigned a range of
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 3.2.4
for a detailed example of filter construction.
The attributes of this class are: 3.1.3. Context Data usage
eventId (InstanceId) For each application signaling protocol there are different pieces
Identifies this object of information that the PDP needs in order to make a provisioning
decision. In some cases the PDP may need IP header information. In
other cases, it may need some state information internal to the PEP
such as the activity timer for a connection or the number of bytes
originating from a particular IP address. Since there are a huge
number of potentially interesting pieces of information that the PDP
may need, sending all the information can be expensive both in
processor and bandwidth overhead. To address this issue, each
EventHandlerElement instance can be independently provisioned with a
list of classes that the PEP should send as part of an Event
message. This list is constructed with a tag reference to a class
called ContextData. Each instance of a ContextData class contains a
class identifier (PRC). The class identifier specifies the type of
ContextData class that should be passed with the Event message.
eventEventHdlr (ReferenceId) Typically a class will represent an autonomous structure such as an
This attribute allows a PEP to indicate to the PDP that this IP header or the fields of a RSVP reservation table entry. In some
event was generated due to the referenced Event Handler. instances such as tunneling, there may be a list of entries that are
This attribute references an event handler via the applicable to the event. For this reason, the ContextData class has
indirection PRC frwkReference, since the event handler and attributes that allow the PDP to indicate whether a specific entry
event could potentially belong to a different PIB contexts. in the list (relative to the beginning or end of the list) or all
the entries in the list should be sent with an Event message. See
Section 3.1.4.5 for details on organization of this class. Also see
Sections 3.2.5 and 3.2.6.2.
eventCause (ReferenceId) 3.1.4. Data Description
This attribute references the specific instance in a 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.
4.2. EventHandler class The following sections the classes defined in the Access Bind PIB.
Instances of this PRC are provisioned by the PDP on the PEP to catch 3.1.4.1. EventHandler class
specific events. The Event Handlers reference a group of Instances of the Event Handler PRC are provisioned by the PDP on the
eventHdlrElement PRIs that contain the scope of the event and 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. specify the context data to send to the PDP when an event is caught.
The attributes of the EventHandler Class are as follows: The attributes of the EventHandler Class are as follows:
eventHandlerId (InstanceId) eventHandlerId (InstanceId)
identifies an instance of this class Identifies an instance of this class.
eventHandlerElements (TagReferenceId) eventHandlerElements (TagReferenceId)
A reference to a group of eventHdlrElement instances, each A reference to a group of eventHdlrElement instances, each
of which determines the scope (criteria for generating a new of which determines the scope (criteria for generating a new
request) and what context information to send in a request. request) and what context information to send in a request.
eventHandlerNonMatchNext (Prid) eventHandlerNonMatchNext (Prid)
The data path for "out of scope" traffic that is not matched The data path for 'out of scope' traffic_ that is not
by one of the eventHdlrElementÆs filter clauses. matched by one of the eventHdlrElement's filter clauses.
4.3. EventHdlrElement class 3.1.4.2. EventHdlrElement class
The PDP installs EventHandlerElements as part of constructing the
event handler. EventHandlerElements describe when events will be
generated and which COPS request handles will be used to send the
requests.
The purpose of the EventHdlrElement is to specify the The purpose of the EventHdlrElement is to specify the
characteristics of the EventHandler. The attributes in the characteristics of the EventHandler. The attributes in the
EventHdlrElement provide maximal reuse by allowing multiple EventHdlrElement provide maximal reuse by allowing multiple
instances of an EventHandler to reuse the same EventHdlrElement instances of an EventHandler to reuse the same EventHdlrElement
instance. Each Instance of this PRC belongs to a group of instance. Each Instance of this PRC belongs to a group of
eventHdlrElement PRIs. The group is identified by the eventHdlrElement PRIs. The group is identified by the
eventHdlrElementGrpId attribute. These are provisioned by the PDP on eventHdlrElementGrpId attribute. These are provisioned by the PDP on
the PEP to catch specific events. This PRC contains the scope of the 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 and specifies the context data type to send to the PDP when an
skipping to change at page 25, line 34 skipping to change at line 1016
both the Event Handler and the Event Handler Element that generated both the Event Handler and the Event Handler Element that generated
the event. the event.
One key aspect of the EventHdlrElement is the Event Criteria One key aspect of the EventHdlrElement is the Event Criteria
attribute. This attribute is used to describe whether unique events attribute. This attribute is used to describe whether unique events
are one time events or repeatable events. For instance, every RSVP are one time events or repeatable events. For instance, every RSVP
message may need to result in a Event Message. However, an Event message may need to result in a Event Message. However, an Event
Message may only be appropriate the first time a new Src IP address Message may only be appropriate the first time a new Src IP address
is seen. After that no events should be generated for that address. is seen. After that no events should be generated for that address.
However other new addresses should still generate Event Messages. However other new addresses should still generate Event Messages.
The Event Criteria attribute defines the frequency with which events The Event Criteria attribute defines the frequency with which events
should be generated. If the Event Criteria is set to One_Time, only should be generated. If the Event Criteria is set to 'One_Time',
one event will ever be generated for that EventHdlrElement when the only one event will ever be generated for that EventHdlrElement when
first match occurs, irrespective of the number of subsequent the first match occurs, irrespective of the number of subsequent
matches. If the Event Criteria is set to Every_Time, each match will matches. If the Event Criteria is set to 'Every_Time', each match
result in an Event Message. A hybrid case is defined called will result in an Event Message. A hybrid case is defined called
On_Change. This option allows a subset of the filter attributes to 'On_Change'. This option allows a subset of the filter attributes to
be required for matching and a different set of attributes that must 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 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 Section 3.2.4 for more details of the behavior of the 'On_Change'
attribute. attribute.
The EventHdlrHandleScope is optional. If it is not specified, itÆs The EventHdlrHandleScope is optional. If it is not specified, it's
behavioral rules are taken from the EventHdlrEventScope objects behavioral rules are taken from the EventHdlrEventScope objects
associated with the relevant EventHdlrElement. In other words, the associated with the relevant EventHdlrElement. In other words, the
criteria for generating Request Handles will be identical to the criteria for generating Request Handles will be identical to the
criteria for generating Event Messages when the EventHdlrHandleScope criteria for generating Event Messages when the EventHdlrHandleScope
is not explicitly specified. is not explicitly specified.
The attributes of the EventHdlrElement class are: The attributes of the EventHdlrElement class are:
eventHdlrElementId (InstanceId) eventHdlrElementId (InstanceId)
identifies the object identifies the object
skipping to change at page 26, line 4 skipping to change at line 1040
behavioral rules are taken from the EventHdlrEventScope objects behavioral rules are taken from the EventHdlrEventScope objects
associated with the relevant EventHdlrElement. In other words, the associated with the relevant EventHdlrElement. In other words, the
criteria for generating Request Handles will be identical to the criteria for generating Request Handles will be identical to the
criteria for generating Event Messages when the EventHdlrHandleScope criteria for generating Event Messages when the EventHdlrHandleScope
is not explicitly specified. is not explicitly specified.
The attributes of the EventHdlrElement class are: The attributes of the EventHdlrElement class are:
eventHdlrElementId (InstanceId) eventHdlrElementId (InstanceId)
identifies the object identifies the object
eventHdlrElementEventCriteria (Unsigned32) eventHdlrElementEventCriteria (Unsigned32)
Indicates when an event is generated. Valid options are Indicates when an event is generated. Valid options are
one_time, every_time and on_change. This attribute allows 'one_time', 'every_time' and 'on_change'. This attribute
event Handlers to distinguish one time events (ignore after allows event Handlers to distinguish one time events (ignore
the first match) from recurring events (generate an event after the first match) from recurring events (generate an
every time a match occurs). An enum type is also define to event every time a match occurs). An enum type is also
specify that a new event should be generated when a specific define to specify that a new event should be generated when
set of fields change. This is important for protocols like a specific set of fields change. This is important for
RSVP because messages are sent both to demonstrate that the protocols like RSVP because messages are sent both to
reservation is active and to notify hops of changes to demonstrate that the reservation is active and to notify
reservations. Since only changes need to propagate to the hops of changes to reservations. Since only changes need to
PDP, the on_change option indicates that that events should propagate to the PDP, the 'on_change' option indicates that
be generated selectively. those events should be generated selectively.
eventHdlrElementGrpId (TagId) eventHdlrElementGrpId (TagId)
Group identifier. All instances with the same group Group identifier. All instances with the same group
identifier belong to one group and can be referenced identifier belong to one group and can be referenced
collectively from an eventHandler instance. collectively from an eventHandler instance.
eventHdlrElementEventScope (TagReferenceId) eventHdlrElementEventScope (TagReferenceId)
Identifies a group of eventHdlrEventScope entries associated Identifies a group of eventHdlrEventScope entries associated
with this eventHdlrElement instance. with this eventHdlrElement instance.
skipping to change at page 26, line 39 skipping to change at line 1076
associated with this eventHdlrElement instance. This is an associated with this eventHdlrElement instance. This is an
optional attribute. optional attribute.
eventHdlrElementContext (TagReferenceId) eventHdlrElementContext (TagReferenceId)
Identifies a list of ContextDataTable entries associated Identifies a list of ContextDataTable entries associated
with this eventHdlrElement instance. with this eventHdlrElement instance.
eventHdlrElementMatchNext (Prid) eventHdlrElementMatchNext (Prid)
The data path for traffic in scope. The data path for traffic in scope.
4.4. EventHdlrEventScope class 3.1.4.3. EventHdlrEventScope class
This PRC defines the scope of an event handler element using This PRC defines the scope of an event handler element using
references to filters defined in the Framework PIB or in some other references to filters defined in the Framework PIB or in some other
PIBs. These filters may describe specific protocol properties for PIBs. These filters may describe specific protocol properties for
which events need to be generated. These filter references are which events need to be generated. These filter references are
grouped using a TagId, and this group is then referenced from the grouped using a TagId, and this group is then referenced from the
eventHdlrElement PRC. eventHdlrElement PRC.
Whenever traffic arrives at the EventHandler for which an Event Whenever traffic arrives at the EventHandler for which an Event
Message has not already been generated, it is compared against the Message has not already been generated, it is compared against the
FilterEntry objects of the EventHdlrEventScope objects referenced by FilterEntry objects of the EventHdlrEventScope objects referenced by
the EventHdlrElement. If it matches the criteria specified in all of the EventHdlrElement. If it matches the criteria specified in all of
the FilterEntry objects, a new Event Message is generated and sent the FilterEntry objects, a new Event Message is generated and sent
to the PDP. The value of EventHdlrElementÆs EventCriteria attribute to the PDP. The value of EventHdlrElement's EventCriteria attribute
in conjunction with the value of the Event Scope classÆs ChangeFlag in conjunction with the value of the Event Scope class's ChangeFlag
attribute determine whether an Event Message will be generated. attribute determine whether an Event Message will be generated.
For example, if a FilterEntry object specifies SRC IP address 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 (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 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 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 the EventCriteria is set to Every_Time for the same attribute
settings, each time a packet contains an IP address within the range settings, each time a packet contains an IP address within the range
an Event Message will be generated. If the EventCriteria is set to an Event Message will be generated. If the EventCriteria is set to
On_Change and the eventHdlrEventScopeChangeFlag is set to True, each On_Change and the eventHdlrEventScopeChangeFlag is set to True, each
skipping to change at page 28, line 11 skipping to change at line 1151
eventHdlrEventScopePrecedence (Integer) eventHdlrEventScopePrecedence (Integer)
Represents the precedence of this criterion with respect to Represents the precedence of this criterion with respect to
other criteria within the same group. When the precedence is other criteria within the same group. When the precedence is
unique, the instance represents an alternative criterion (an unique, the instance represents an alternative criterion (an
OR function). When the precedence for two or more instances OR function). When the precedence for two or more instances
of the eventHdlrEventScope class is the same, the attributes of the eventHdlrEventScope 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.
eventHdlrEventScopeChangeFlag (TruthValue) eventHdlrEventScopeChangeFlag (TruthValue)
Boolean value, if set to "True" indicates that a new event Boolean value, if set to 'true' indicates that a new event
should be generated if any of the assigned fields in the should be generated if any of the assigned fields in the
associated filter change. associated filter change.
4.5. EventHdlrHandleScope class 3.1.4.4. EventHdlrHandleScope class
This PRC defines the scope of Request Handles generated by the PEP This PRC defines the scope of Request Handles generated by the PEP
due to events caught by the Event Handler Element. Each instance of due to events caught by the Event Handler Element. Each instance of
this PRC references filters defined in the Framework PIB or some this PRC references filters defined in the Framework PIB or some
other signaling-protocol specific filter PRCs. These filters may other signaling-protocol specific filter PRCs. These filters may
describe specific protocol properties to which this Event Handler is describe specific protocol properties to which this Event Handler is
sensitive. Essentially this table defines when a new COPS Request sensitive. Essentially this table defines when a new COPS Request
Handles must be created by the PEP based on protocol properties. The 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 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 and/or the uniqueness of a set of values considered together. This
skipping to change at page 28, line 45 skipping to change at line 1185
created. It is important to note that the attributes determining created. It is important to note that the attributes determining
when a new Handle is created MUST be a subset of the filter when a new Handle is created MUST be a subset of the filter
attributes and filter values specified for the EventHdlrEventScope. attributes and filter values specified for the EventHdlrEventScope.
The reason for this is that an Event Message MUST use one of the 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 available Request Handles to notify the PDP of an Event. If the
attributes and values used in the EventHdlrEventScope are not a attributes and values used in the EventHdlrEventScope are not a
superset of the attributes and values EventHdlrHandleScope, then superset of the attributes and values EventHdlrHandleScope, then
there may be no valid Handle over which the Event Message can be there may be no valid Handle over which the Event Message can be
sent to the PDP. sent to the PDP.
The EventHdlrHandleScope is optional. If it is not specified, itÆs The EventHdlrHandleScope is optional. If it is not specified, it's
behavioral rules are taken from the EventHdlrEventScope objects behavioral rules are taken from the EventHdlrEventScope objects
associated with the relevant EventHdlrElement. In other words, the associated with the relevant EventHdlrElement. In other words, the
criteria for generating Request Handles will be identical to the criteria for generating Request Handles will be identical to the
criteria for generating Event Messages when the EventHdlrHandleScope criteria for generating Event Messages when the EventHdlrHandleScope
is not explicitly specified. is not explicitly specified.
See Sections 4.3 and 4.6 for more details on the operational See Sections 3.1.2 and 3.2.4 for more details on the operational
behavior of this class. behavior of this class.
eventHdlrHandleScopeId (InstanceId) eventHdlrHandleScopeId (InstanceId)
An arbitrary integer index that uniquely identifies an instance of An arbitrary integer index that uniquely identifies an
the eventHdlrHandleScopeTable class. instance of the eventHdlrHandleScopeTable class.
eventHdlrHandleScopeGroup (TagId) eventHdlrHandleScopeGroup (TagId)
Represents the binding between the eventHdlrElementEntry and the Represents the binding between the eventHdlrElementEntry and
eventHdlrHandleScope entries. A group of eventHdlrHandleScope the eventHdlrHandleScope entries. A group of
entries constitutes the criteria for defining the scope of the eventHdlrHandleScope entries constitutes the criteria for
Handles generated. defining the scope of the Handles generated.
eventHdlrHandleScopeFilter (Prid) eventHdlrHandleScopeFilter (Prid)
Pointer to a filter to be used as the criteria. Pointer to a filter to be used as the criteria.
eventHdlrHandleScopePrecedence (INTEGER) eventHdlrHandleScopePrecedence (INTEGER)
Represents the precedence of this criterion with respect to other Represents the precedence of this criterion with respect to
criteria within the same group. When the precedence is unique, the other criteria within the same group. When the precedence is
instance represents an alternative criteria (an ORing function). unique, the instance represents an alternative criteria (an
When the precedence for two or more instances of the ORing function). When the precedence for two or more
eventHdlrHandleScope class is the same, the attributes within all instances of the eventHdlrHandleScope class is the same, the
the instances are treated collectively as a single filter criteria. attributes within all the instances are treated collectively
as a single filter criteria.
eventHdlrHandleScopeChangeFlag (TruthValue) eventHdlrHandleScopeChangeFlag (TruthValue)
Boolean value, if set to "True" indicates that a new Handle should Boolean value, if set to 'true' indicates that a new Handle
be generated if any of the assigned fields in the associated filter should be generated if any of the assigned fields in the
change. associated filter change.
The PDP installs EventHandlerElements as part of constructing the 3.1.4.5. ContextData class
event handler. EventHandlerElements describe when events will be
generated and which COPS request handles will be used to send the
requests.
4.6. Behavior of the Event and Handle Scope classes 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.
The attributes of this class are:
ContextDataId (InstanceId)
Identifies this object
ContextDataGroup (TagId)
Defines the grouping of contextData instances that are
applicable to a given eventHdlrElement.
ContextDataIfElement (PrcIdentifier)
The OID of a class whose instance is to be included with
the PEP request or event-specific ContextData Response.
ContextDataEncapsulation (Integer)
This attribute allows one to distinguish between inner and
outer headers when there are multiple encapsulated headers
of the same type in a packet.
A value of:
0 means all headers,
positive number 'n' means the 'n'th header starting
from the outermost,
negative number 'n' means the 'n'th header starting from
the innermost.
3.2. Event Handling
As soon as the PEP detects a situation described by an event
handler, it must trigger an event. If an event is triggered, the PEP
must send a message to the PDP that installs the event handler. This
section describes how this message looks like.
3.2.1. Functional Description
The event message that the PEP needs to send to the PDP is a common
COPS-PR request message, containing exactly one event data
structure, and optionally zero or more context data classes,
depending on which eventHandlerElement triggered the event. Context
Data classes are described in chapter 4.
An event message typically represents an access request of a client,
the decision for which the PEP outsources to the PDP. See Figure
3.3.
time
| +---+ +---+
| | |-- provisioning req. ->| |
| | |<-- provisioning ------| |
| | P | | P |
| | E |--- event ------------>| D |
| | P | | P |
| | |<-- decision ----------| |
V +---+ +---+
Figure 3.3: Simple message sequence for provisioning and events.
3.2.2. COPS Client Handle
The event and the decision are associated with each other using the
COPS Client Handle, which is described in section 2.2.1 of RFC 2748.
Each COPS message contains this Client Handle, which serves as an
identifier to match request and response, and can later be used to
remove an earlier install decision.
Because the COPS Client Handle serves as a connection between the
request and the decision, there must not be more then one
outstanding COPS request with the same Client Handle. It is possible
to have multiple outstanding COPS requests, as long as their Client
Handle is different.
For most applications, the PEP will generate a new unique COPS
Client Handle for each event. However, in some situation it can be
useful if the same client handle is used for multiple events. This
implies that the second even can only be sent after the PDP sent a
response for the first event. The PDP can explicitly specify when
the PEP must use a new COPS Client Handle, by using the
eventHdlrElementHandleScope. This should point to a scope, similar
to the eventHdlrElementEventScope. Only when the criteria in the
eventHdlrElementHandleScope matches, the PEP must create a new COPS
Client Handle.
3.2.3. DiffServ element
In case the Event Handler is part of a DiffServ model, the
EventHandler acts as a Classifying DiffServ element. If no criteria
are met, the ingress traffic for this element is forwarded to the
DiffServ element specified by the eventHandlerNonMatchNext attribute
in the EventHandler instance. If a criteria is met, traffic
belonging to this ingress dataflow is dropped (or forwarded to the
PDP, as is shown in chapter 7), until the PDP responds to the
outstanding request. If the response is affirmative, the properties
of the ingress dataflow, as specified by the
eventHdlrElementEventCriteria and eventHdlrEventScopeChangeFlags are
stored, typically in a lookup-table, and all traffic coming from
this ingress dataflow is forwarded to the DiffServ element specified
by the eventHdlrElementMatchNext attribute. If the response from the
PDP is negative, the authorization failed, and the PEP can just
forward the traffic to the eventHandlerNonMatchNext until an event
is triggered.
An affirmative reply from the PDP is defined as a COPS-PR Decision
message with the command in the Decision flag object set to Install
(section 2.2.6 of RFC 2748). An example of how the EventCriteria and
ChangeFlags specify a filter is given in 3.1.2, while section 3.2.4
further clarifies the scopes.
3.2.4. Behavior of the Event and Handle Scope classes
The rules for interpreting Handle Scope and Event Scope are the The rules for interpreting Handle Scope and Event Scope are the
same. One is applied to Handles and the other is applied to Events. same. One is applied to Handles and the other is applied to Events.
Some of the classes used by the Access Bind PIB are the Filter
classes described in the COPS-PR Framework PIB [FWPIB]. These
classes allow a PDP to specify a set of 802.1 and IP header field
values that can be matched against packets. The Event Scope and
Handle Scope classes can use these filter classes as well as other
filter classes to define the criteria for generating an event.
Each scope class (Event Scope or Handle Scope) instance has a Each scope class (Event Scope or Handle Scope) instance has a
precedence value associated with it. When two or more scope class precedence value associated with it. When two or more scope class
instances of the same type (event vs handle) have the same instances of the same type (event vs. handle) have the same
precedence number, they are considered part of the same rule. For precedence number, they are considered part of the same rule. For
example, the table below lists a set of Event Scope class instances, example, table 3.1 lists a set of Event Scope class instances, their
their precedence values and the filter field names and values precedence values and the filter field names and values associated
associated with each instance: (FName is the field name) with each instance (FName is the field name):
Instance Precedence FName/Val FName/Val FName/Val Instance Precedence FName/Val FName/Val FName/Val
-------- ---------- --------- --------- --------- -------- ---------- --------- --------- ---------
1* 2 W/20 X/2-4 1* 2 W/20 X/2-4
2* 1 A/5-6 B/15 C/10-11 2* 1 A/5-6 B/15 C/10-11
3 2 W/14 Y/500-550 3 2 W/14 Y/500-550
4 2 Q/4-9 R/92 4 2 Q/4-9 R/92
This example would result in events being generated when one of the
two expressions below are matched: Table 3.1: List of Filter rules
This example would result in the following two filter expressions:
1. (A=5 or A=6) and (B=15) and (C=10 or C=11 or C=12) 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) 2. (W=20 or W=14) and (X=2-4) and (Y=500-550) and (Q=4-9) and (R=92)
If the EventCriteria was set to "OneTime", then if either 1 or 2 is If the EventCriteria was set to 'One Time', then if either 1 or 2 is
matched, one event will be generated and this particular Event matched, one event will be generated and this particular Event
Handler Element will generate no further events. Note that if Handler Element will generate no further events. Note that if
matches occur but the "OneTime" event has already been generated, matches occur but the 'One Time' event has already been generated,
the Event Hander Element's MatchNext attribute may still determine the Event Hander Element's MatchNext attribute may still determine
what the next forwarding action is for the packet event thought no what the next forwarding action is for the packet event even though
event is generated. no event is generated.
If the EventCriteria was set to "EveryTime", then every matching If the EventCriteria was set to 'Every Time', then every matching
packet will cause an event. If the EventCriteria was set to packet will cause an event. If the EventCriteria was set to 'On
"OnChange", then events will be generated the first time a unique Change', then events will be generated the first time a unique
combination of attributes is seen. Setting the ChangeFlag in the combination of attributes is seen. Setting the ChangeFlag to 'True'
EventScope class (denoted by the asterisks in the previous example), in the EventScope class (denoted by the asterisks next to the
identifies the set of attributes for which unique combinations of Instance number in Table 3.1), identifies the set of attributes for
values generated new events. which unique combinations of values generated new events. The
ChangeFlag is applied to the attribute, not the specific instance of
the filter. Therefore, even though instance 3 does not have the
ChangeFlag set, the values for attribute W specified in instance 3
will be treated as if the ChangeFlag was set for that attribute, as
per example 8 below.
Continuing the example above the following table shows a stream of Continuing the example above the following table shows a stream of
packets and whether an event will be generated. packets and whether an event will be generated.
1. A=5, B=19, C=10 No Event (B did not match) 1. A=5, B=19, C=10 No Event (B did not match)
2. A=5, B=15, C=10 Event (Unique pairing of A & C) 2. A=5, B=15, C=10 Event (Unique pairing of A & C)
3. A=6, B=15, C=11 Event (Unique pairing of A & C) 3. A=6, B=15, C=11 Event (Unique pairing of A & C)
4. W=20, X=2, Y=500, Q=4, R=92 Event (Unique pairing of W & X) 4. W=20, X=2, Y=500, Q=4, R=92 Event (Unique pairing of W & X)
5. W=20, X=2, Y=505, Q=9, R=92 No Event (Already have a 5. W=20, X=2, Y=505, Q=9, R=92 No Event (Already have a
matched for W & X) matched for W & X)
6. A=5, B=15, C=11 Event (Unique pairing of A & C) 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 7. A=5, B=15, C=10 No Event (Already have a
matched for A & C) matched for A & C)
8. W=20, X=3, Y=502, Q=7, R=95 No Event (no match on R)
9. W=14, X=2, Y=500, Q=4, R=92 Event (Unique pairing of W & X)
4.7. EventHdlrAuthProtocol class 3.2.5. Context Data Entries
This
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:
EventHdlrAuthProtocolId (InstanceId)
Identifies this object
EventHdlrAuthProtocolGroup (TagId) Section 3.1.3 described the ContextData class and how it is used to
Represents a binding between an datapathEventHdlrTable provision the set of event-specific information elements that must
instance and a list of eventHdlrAuthProtocolTable instances. be included with each Event Message. This section provides an
overview of the format of the actual information elements.
EventHdlrAuthProtocolAuthMechanism (Enum) Each Context Data Entry is organized to logically describe a layer
Specifies an authentication mechanism to be used in Event or grouping of attributes. The downside of this strategy is that
Messages triggered by the EventHandler referencing this when a specific entry is requested, all the fields in the entry must
EventHdlrAuthProtocol object. The value is from an be filled before the entry can be sent to the PDP. This is a
enumerated list initially consisting of (PAP, CHAP, EAP-MD5, compromise between forcing the PDP to describe all the fields
and EAP-TLS) explicitly and making the PEP send all attributes of possible
interest. Since a given PDP knows better what it needs to generate a
decision than a PEP, the second alternative is extremely unwieldy.
On the other hand, forcing the PDP to describe all the fields
necessary for a given event, would create an explosion of object
definitions.
4.8. DatapathEventHdlr Class In sections 3.2.6.2, there are two classes that are defined as part
This PRC is an extension of the EventHandler PRC. This extension of the Access Bind PIB. These objects define the relevant fields of
illustrates the use of the EventHandler PRC concept for a Ethernet header and a IP header. It was determined that these
authentication usage. Instances of this PRC are provisioned by the headers existed in a large enough cross-section of application-
PDP on the PEP to catch specific events that require authentication specific signaling PIBs, that they belonged in the Access Bind PIB.
processing. This PRC references a group of eventHdlrAuthProtocol This does not impact those application-specific signaling PIBs that
instances that define a set of Authentication mechanisms to use if don't use one or both headers. Since the PDP request only those
an access event is caught by this event Handler. From its base class headers relevant to each application specific event, these classes
(Event Handler) this PRC also references a group of eventHdlrElement do not need to be implemented in order to meet the compliance
PRIs that contain the scope of the access event and specify the requirements for this PIB.
context data to send to the PDP when an access event is caught.
The attributes of this class are: 3.2.6. Data Description
datapathEventHdlrRequestAuth (TruthValue)
Boolean flag, if set to "True" requires authentication data
to be sent in the Event Message sent to the PDP.
datapathEventHdlrAuthProtocol (TagReferenceId) This section describes the behavior of all classes associated with
References a group of eventHdlrAuthProtocol instances, each the generation of event messages to the PDP.
of which specifies an authentication mechanism.
4.9. ContextData class 3.2.6.1. Event class
This PRC specifies the context information to send to the PDP when Instances of this table represent events that occurred at the PEP.
an event is caught. The context information to send is described in The events reference the event handler instance and the specific
terms of the PRC data types to include in the request, the level of event handler element that the event was caught by.
encapsulated data and the interface information for that request.
The attributes of this class are: The attributes of this class are:
ContextDataId (InstanceId) eventId (InstanceId)
Identifies this object Identifies this object
ContextDataGroup (TagId) eventEventHdlr (ReferenceId)
Defines the grouping of contextData instances that are This attribute allows a PEP to indicate to the PDP that this
applicable to a given eventHdlrElement. event was generated due to the referenced Event Handler.
This attribute references an event handler via the
ContextDataIfElement (PrcIdentifier) indirection PRC frwkReference, since the event handler and
The OID of a class whose instance is to be included with event could potentially belong to a different PIB contexts.
the PEP request or event-specific ContextData Response.
ContextDataEncapsulation (Integer)
This attribute allows one to distinguish between inner and
outer headers when there are multiple encapsulated headers
of the same type in a packet.
A value of: eventCause (ReferenceId)
0 means all headers, This attribute references the specific instance in a group
positive number 'n' means the 'n'th header starting of event Handler elements belonging to an event Handler that
from the outermost, resulted in this event. This attribute references a specific
negative number 'n' means the 'n'th header starting from event handler element via the indirection PRC frwkReference,
the innermost. since the event handler element and event could potentially
belong to a different PIB contexts.
4.10. ContextData classes 3.2.6.2. 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
Event Message for various types of eventHdlrElements. 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.10.1. CtxtL3Hdr class 3.2.6.2.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
Event Message to be generated. Event Message to be generated.
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
CtxtL3HdrDstAddrType (Enum) CtxtL3HdrDstAddrType (Enum)
specifies the type of the packetÆs layer 3 destination specifies the type of the packet's layer 3 destination
address address
CtxtL3HdrDstAddr CtxtL3HdrDstAddr
the packetÆs layer 3 destination address the packet's layer 3 destination address
CtxtL3HdrProtocol CtxtL3HdrProtocol
the packetÆs protocol field the packet's protocol field
CtxtL3HdrSrcPort CtxtL3HdrSrcPort
the packetÆs source port field the packet's source port field
CtxtL3HdrDstPort CtxtL3HdrDstPort
the packetÆs destination port field the packet's destination port field
CtxtL3HdrDscp CtxtL3HdrDscp
the packetÆs Type of Service (Diffserv Code Point)field the packet's Type of Service (Diffserv Code Point)field
CtxtL3HdrEcn (boolean) CtxtL3HdrEcn (boolean)
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 EventHandler (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.
4.10.2. Ctxt802Hdr class 3.2.6.2.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
Event Message 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
the frameÆs destination MAC address the frame's destination MAC address
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 Event Handler (or the explicitly depending on how the Event Handler (or the explicitly
requested PDP Context Data request) was specified using requested PDP Context Data request) was specified using
negative or 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
skipping to change at page 34, line 16 skipping to change at line 1576
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 Event Handler (or the explicitly depending on how the Event Handler (or the explicitly
requested PDP Context Data request) was specified using requested PDP Context Data request) was specified using
negative or 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.10.3. CtxtDialupInterface class 4. Identity Extensions PIB module
The CtxtDialupInterface class specifies data to be included in Event The Access Bind PIB provides a basic framework for processing PEP
Messages sent by Event Handlers providing dialin services. events. A subset of events require identity management of some type.
In some cases this means that the PDP, PEP and end system are
involved in some type of authentication process. An Identity
Extensions PIB is provided that extends the EventHandler class and
adds some Authentication Protocol specific classes. This PIB is
described in detail below.
The attributes of this class are: 4.1. Functional Description
CtxtDialupInterfaceId In the operational model for this PIB, the Authentication Server is
identifies this object a specific function of the PDP. The main purpose of the
authentication portions of this PIB is to verify the validity of
client credentials by an Authentication Server. The verification
process itself may do this whilst ensuring some level of
authenticity, confidentiality and integrity. Messages exchanged
between a Client and Authentication Server (PDP) may remain
confidential to PEP's and Proxy Servers. The message integrity may
be ensured by some hashing algorithm so PEP's and Proxy's may
inspect but not modify the content of authentication messages.
Clients, PEP's, Proxy's and PDP's will always need some security
method to ensure message authenticity.
CtxtDialupInterfaceNASPort Some authentication protocols explicitly consider proxies by
This attribute indicates the physical port number of allowing the payload to be carried over a variety of transports.
the NAS which is authenticating the user. Note that this is Others depend on the termination point of the connection to
using 'port' in its sense of a physical connection on the explicitly proxy the authentication, when that is necessary. In
NAS, not in the sense of a TCP or UDP port number. Either order to demonstrate the general utility of this model, a variety of
CtxtDialupInterfaceNasPort or CtxtDialupInterfaceNasPortType client authentication protocols will be considered in this document.
or both SHOULD be specified in a CtxtDialupInterface object, For each protocol, the negotiation mechanism will be described and
if the NAS differentiates among its ports. the mapping to this framework will be detailed.
CtxtDialupInterfaceNASPortId 4.1.1. Provisioning
This attribute contains a text string which identifies the
port of the NAS which is authenticating the user. Note that
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.
Either CtxtDialupInterfaceNasPort or
CtxtDialupInterfaceNasPortId SHOULD be specified in a
CtxtDialupInterface object, if the NAS differentiates among
its ports. CtxtDialupInterfaceNasPortId is intended for use
by NASes which cannot conveniently number their ports.
CtxtDialupInterfaceNASPortType (Enum) The PEP will not start an authentication sequence with the client if
This attribute indicates the type of the physical port it hasn't been told to do that. It will only do so when a specific
of the NAS which is authenticating the user. It can be event occurs. The PDP tells the PEP exactly when this event should
used instead of or in addition to the be triggered. This process is called provisioning.
CtxtDialupInterfaceNasPort attribute.
CtxtDialupInterfaceCalledStationId The provisioning starts with the initial Provisioning Request, which
This attribute allows the NAS to send the phone number that is typically sent at boot time. The PEP sends up capability PRC's
the user called, using Dialed Number Identification (DNIS) indicating the types of authentication it can handle. The PDP will
or similar technology. Note that this may be different from reply by setting the following Access Bind PRC's:
the phone number the call comes in on. a. identEventHandler (IdentityEventHandler)
b. identEventhdlrAuthProtocol
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.
CtxtDialupInterfaceCallingStationId In case the PDP wants the PEP to perform an authentication when an
This attribute allows the NAS to send the phone number that event is triggered, provisions an Identity Event Handler
the call came from, using Automatic Number Identification (identEventHandler) instead of the standard Event Handler. The
(ANI) or similar technology. Identity Event Handler has a few extra attributes in the class to
allow the PDP to indicate what authentication protocols to use and
whether authentication is mandatory. This is done by setting the
identEventhdlrRequestAuth in the identEventHdlr to true and
optionally letting the identEventHdlrAuthProtocol field reference a
eventHdlrAuthProtocol tagid to indicate which authentication
protocols should be used for the authentication.
CtxtDialupInterfaceConnectInfo As soon as the PDP has provisioned the PEP to watch for certain
This attribute is sent from the NAS to indicate the traffic that triggers an event, the PEP is ready to start an
nature of the user's connection. authentication.
This is a notify-only class. These attributes are not write-able by 4.1.2. EAP Authentication
the PDP.
Three additional notify/install classes can be defined. These The most significant aspect distinguishing EAP [EAP] from other
classes can be included in an Event Message as information to the authentication protocols is that EAP assumes the negotiation is
PDP. The PDP may change the values of these attributes, however, in between the client and the authentication server. In anticipation of
subsequent provisioning messages. the fact that the terminating point of a connection such as PPP or
L2TP is not necessarily the same as the agent managing client
authentication, EAP encapsulates it's negotiation process in a
separate header that can be forwarded in entirety to the server.
This mechanism provides extra security by preventing intermediate
proxies from monitoring or managing authentication credentials.
4.10.4 CtxtDialupIfFramedProtocol class EAP supports a number of different authentication mechanisms
including MD5, TLS, and One-Time-Password authentication.
The CtxtDialupIfFramedProtocol class is an optional class that may The terminology used in [EAP] differs from the terminology used in
be sent if a framed protocol is being used. This class MAY be this document. In particular, the peer, as defined in section 1.2 of
specified in the ContextData PRC by the PDP in a decision message if [EAP], is referred to as 'Client' in this document. Similarly, the
the PDP needs this context information (if it was not already setup 'authenticator' is called a PEP in this document and 'back-end
to be sent in the eventHandler). It MUST be sent up to the PDP in a server' is called the Authentication Server function of the PDP (or
request message if it is specified via the ContextData PRC in an just PDP) in this document.
eventHandler.
The attributes of this class are:
CtxtDialupIfFramedProtocolId 4.1.2.1. EAP Message sequence
identifies this object
CtxtDialupIfFramedProtocolProt The generic sequence of transmissions between the PEP and PDP has
This attribute indicates the framing to be used for already been described in section 2. In particular, figure 2.1 gives
framed access. an overview of the messages involved between the Client workstation,
PEP and PDP. EAP messages are embedded in PPP packets in the
communication between the Client and the PEP. In the communication
between the PEP and PDP, the EAP messages are embedded in COPS
Request, COPS Decision and COPS Report messages. Figure 4.1 shows
how EAP may be used to retrieve credentials from the client
workstation by the PDP.
CtxtDialupIfFramedProtocolMTU time
This attribute indicates the Maximum Transmission Unit to be | +---+ +---+ +---+
configured for the user, when it is not negotiated by some | | | | |-- COPS-PRC exchange ---->| |
other means (such as PPP). | | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-EAP --| | | |
| | U |-- PPP LCP ACK-EAP ->| P | | P |
| | s |<- PPP EAP Req Id ---| E | | D |
| | e |-- PPP EAP Res Id -->| P | | P |
| | r | | |-- COPS-Req Ses-EAP ---->| |
| | | | |<- COPS-Dec EAP Req Chal -| |
| | |<- PPP EAP Req Chal -| | | |
| | |- PPP EAP Res Chal ->| | | |
| | | | |- COPS-Rep EAP Res Chal ->| |
| | | | | | |
| | | | |<- COPS-Dec EAP Success --| |
| | |<- PPP EAP success --| | | |
V +---+ +---+ +---+
CtxtDialupIfFramedProtocolCompression (Enum) Figure 4.1: Embedding of EAP messages between the Client workstation
This attribute indicates a compression protocol to be used and the PEP, and between the PEP and PDP. The EAP messages may be
for the link. opaque to the PEP.
CtxtDialupIfFramedProtocolPortLimit Typically, when the PEP boots up, it sends it's capabilities to the
This attribute sets the maximum number of ports to be PDP in a COPS message and is than configured by the PDP with one or
provided to the user by the NAS. It is intended for use in more datapathEventHandlers specifying the criteria for generating
conjunction with Multilink PPP or similar uses. PEP Event Messages. The first message after this provisioning
process from the PEP to the PDP is a new Event Message. The PEP
sends a COPS request to 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 EAP 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 of which Filter (by means of the
eventhdlrEventScope) triggered the event.
CtxtDialupIfFramedProtocolIpAddress All EAP messages necessary to complete the authentication process
This attribute indicates the address to be configured for will be forwarded to the PDP. All of the negotiation occurs between
the user. It MAY be used in constructing policies for the the Client and the PDP and should, except for the EAP message code
user. field, not be examined by the PEP. In order to support multiple EAP
protocols, this PIB supports a generic EAP request class and EAP
response class. Each class has a single string attribute
(authEapReqExtSpecific and authEapRespExtSpecific, respectively)
within which the entire EAP message is passed.
CtxtDialupIfFramedProtocolIpNetmask Although figure 4.1 shows two EAP messages going from the PDP to the
This attribute indicates the IP netmask to be Client and two EAP messages being returned from the client to the
configured for the user when the user is a router to a PDP, the actual number of messages exchanged can be any amount. The
network. 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
credentials from the client, the PDP may continue to provision the
PEP with policies. This is action is not shown in figure 4.1.
4.10.5 CtxtDialupIfLoginService class The PDP should end the EAP negotiation with an EAP Success or an EAP
Failure message. If the PDP sends a EAP Success, the PEP must from
then on use the matchNext Prid to determine the next processing
filter for data defined by the values described using the
eventhdlrEventScope.
The CtxtDialupIfLoginService class is an optional class that may be 4.1.3. PAP Authentication
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.
This class contains a single attribute: PAP (Password Authentication Protocol), as described in section 2 of
[AUTH] is a very simple authentication mechanism used over PPP. It
is not considered to be a secure mechanism, since it sends passwords
over the wire in clear text format. However, where one-time
passwords are used, this security concern is mitigated. It is
described here nonetheless for illustration purposes and because it
may still be used among ISPs, or in situations where another layer
already performs encryption for security.
CtxtDialupIfLoginIpHost The terminology used in [AUTH] differs from the terminology used in
This attribute indicates the system with which to connect he this document. In particular, the peer as defined in section 1.2 of
user. [AUTH] is referred to as 'Client' in this document. Similar, the
'authenticator' is called PEP in this document.
4.10.6 CtxtDialupIfLoginLat class 4.1.3.1. PAP Connection sequence
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 Figure 4.2 shows how PAP may be used to retrieve credentials from
CtxtDialupInterfaceLoginService class. Its attributes are: the client workstation by the PDP.
CtxtDialupIfLoginLatService time
This attribute indicates the system with which the user | +---+ +---+ +---+
is to be connected by LAT. | | | | |-- COPS-PRC exchange ---->| |
| | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-PAP --| | | |
| | U |-- PPP LCP ACK-PAP ->| P | | P |
| | s |-- PPP PAP Id, Pwd ->| E | | D |
| | e | | P |-- COPS-Req event, -->| P |
| | r | | |-- userPapExt -->| |
| | | | | | |
| | | | |<- COPS-Dec eventElement -| |
| | | | |<- COPS-Dec authResult ---| |
| | |<- PPP PAP ack ------| | | |
V +---+ +---+ +---+
CtxtDialupIfLoginLatNode Figure 4.2: Embedding of PAP messages between the Client workstation
This attribute indicates the Node with which the user is to and the PEP, and between the PEP and PDP.
be automatically connected by LAT.
CtxtDialupIfLoginLatGroup When the dpEventHandler has been configured to require
This attribute contains a string identifying the LAT group authentication, a PEP Event message will not be generated until
codes which this user is authorized to use. 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.
LAT supports 256 different group codes, which LAT uses as a The Client will send the Identity and Password to the PEP. The PEP
form of access rights. LAT encodes the group codes as a 256 will embed the password into the userPapExt datastructure and send
bit bitmap. this to the PDP. Since this datastructure inherits the fields of the
userAuthExt data structure and the extAuth data structure, it will
also contain the PAP identity attribute inserted into the
authUsername attribute of this Instance.
Administrators can assign one or more of the group code bits The first connection from the PEP to the PDP is an alert that an
at the LAT service provider; it will only accept LAT event was triggered. The PEP sends an Event Message over COPS to the
connections that have these group codes set in the bit map. PDP containing a new instance of the Event table. The eventEventHdlr
The administrators assign a bitmap of authorized group codes attribute in the Event table entry is a ReferenceId that points to a
to each user; LAT gets these from the operating system, and dpeventHandler entry indicating (by means of the
uses these in its requests to the service providers. 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.
CtxtDialupIfLoginLatPort Besides these required instances, the PEP might have been configured
This attribute indicates the Port with which the user is to by the PDP to sent additional information about the client to the
be connected by LAT. 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.
4.11. AuthExt class 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.
4.1.4. CHAP Authentication
CHAP (Challenge Authentication Protocol) [CHAP] is a strong
authentication mechanism, which eliminates the need to send
passwords in the clear, like PAP does. With CHAP, the Authenticator
generates a challenge key, sends it to the Peer (Client) and the
client responds with a cryptographically hashed response that
depends upon the Challenge and a secret key. The PDP checks the
secret key by performing the same encryption and comparing the
results.
The terminology used in [CHAP] differs from the terminology used in
this document. In particular, the peer as defined in section 1.2 of
[CHAP] is referred to as 'Client' in this document. Similar, the
'authenticator' is called PEP in this document.
4.1.4.1. CHAP Connection sequence
Figure 4.3 shows how CHAP may be used to retrieve credentials from
the client workstation by the PDP.
time
| +---+ +---+ +---+
| | | | |-- COPS-PRC exchange ---->| |
| | | | |<- COPS-Dec eventHandler -| |
| | |-- PPP traffic ----->| | | |
| | |<- PPP LCP Req-CHAP -| | | |
| | U |- PPP LCP ACK-CHAP ->| P | | P |
| | s |<- PPP CHAP Chal ----| E | | D |
| | e |-- PPP CHAP Ident, ->| P | | P |
| | r |-- Id, Resp ->| | | |
| | | | |-- COPS-Req event-CHAP -->| |
| | | | |-- COPS-Rep CHAP Resp, -->| |
| | | | |-- Chal -->| |
| | | | | | |
| | | | |<- COPS-Dec eventElement -| |
| | | | |<- COPS-Dec authResult ---| |
| | |<- PPP CHAP ack -----| | | |
V +---+ +---+ +---+
Figure 4.3: Embedding of CHAP messages between the Client
workstation and the PEP, and between the PEP and PDP.
As soon as the PEP finished negotiating CHAP as the Authentication
protocol, it generates a challenge itself, and sends this to the
Client. The client will respond to this authentication request by
sending his or her identity, an identifier and the response. The
response is a cryptographically encrypted hash based on the
challenge and secret key (password).
The identifier is only used to keep track of CHAP messages, and
needs to be used by the PEP to recover the associated challenge.
The first connection from the PEP to the PDP is a notice of a new
Event. The PEP sends an Event Message to 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 CHAP
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 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.
Note that having the PEP issue the challenge allows the PEP to
perpetrate fraud by issuing a replayed request (assuming that the
PEP and PDP are in different domains). The only guard against this
is for the PDP to check that multiple authentication requests for
the same client have unique challenges. This may be slow. PDP and
Authentication server developers who feel this is a security issue
may want to use EAP-MD5 authentication rather then CHAP
authentication, since EAP-MD5 addresses this problem by letting the
PDP generate the challenge.
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 PDP performs the CHAP authentication. When the authentication is
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.
4.2. Data Description
This section describes each of the classes defined in the Identity
Extension PIB module.
4.2.1. IdentityEventHdlr Class
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 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.
The attributes of this class are:
identityEventHdlrRequestAuth (TruthValue)
Boolean flag, if set to 'true' requires authentication data
to be sent in the Event Message sent to the PDP.
identityEventHdlrAuthProtocol (TagReferenceId)
References a group of identityHdlrAuthProtocol instances,
each of which specifies an authentication mechanism.
4.2.2. EventHdlrAuthProtocol class
This 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 control policies assigned to
them.
The attributes of this class are:
eventHdlrAuthProtocolId (InstanceId)
Identifies this object
eventHdlrAuthProtocolGroup (TagId)
Represents a binding between an datapathEventHdlrTable
instance and a list of eventHdlrAuthProtocolTable instances.
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)
4.2.3. AuthExt class
This is an abstract PRC. This PRC can be extended by authentication This is an abstract PRC. This PRC can be extended by authentication
PRCs that contain attributes specific to that authentication PRCs that contain attributes specific to that authentication
protocol. An instance of the extended class is created by the PEP 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 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. may use the information to authenticate the PEP's Event Message.
This PRC itself should not be instantiated. This PRC itself should not be instantiated.
Typically this class and it's subclasses are included as part of an
event message containing the Event class (Section 3.2.6.1).
The data in this class is passed between the PDP and the client with 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 little or no involvement of the PEP except to forward it in the
appropriate AuthExt class instance. The PEP is not meant to store appropriate AuthExt class instance. The PEP is not meant to store
AuthExt objects. As such, this class, along with all its extending AuthExt objects. As such, this class, along with all its extending
classes, is meant to be 'transient'. Its instances are temporary and 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 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 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 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 instances sent by the PDP. Also, since instances are deleted, it is
possible for InstanceIds to be reused. possible for InstanceIds to be reused.
The AuthExt class is extended for each authentication mechanism The AuthExt class is extended for each authentication mechanism
supported. As a base class, it is never instantiated. supported. As a base class, it is never instantiated.
The attributes of this class are: The attributes of this class are:
AuthExtId (InstanceId) AuthExtId (InstanceId)
identifies this object identifies this object
4.11.1. UserAuthExt class 4.2.4. UserAuthExt class
This is a concrete PRC used to contain user authentication fields. This is a concrete PRC used to contain user authentication fields.
This PRC extends the base PRC authExtEntry. This PRC extends the base PRC authExtEntry.
The attributes of this class are: The attributes of this class are:
userAuthExtRealm (OCTET STRING) userAuthExtRealm (OCTET STRING)
The user realm octet string. The user realm octet string.
userAuthExtUsername (OCTET STRING) userAuthExtUsername (OCTET STRING)
The Username octet string. The Username octet string.
4.11.2. AuthChapExt class 4.2.5. AuthExtResult class
The AuthChapExt class extends the UserAuthExt class. It contains the
attributes of the CHAP protocol [CHAP]. (See section 3.3.) All authentication message sequences conclude with an authentication
result message sent from the PDP to the PEP. This message is usually
accompanied by one or more provisioning decisions associated with
the authenticated identity. 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: The attributes that this class adds to the base class are:
AuthChapExtId (Unsigned32) AuthExtSuccessful (TruthValue)
The AuthChapExtId is generated by the PEP. The ID value is A Boolean flag set to true if the authentication (via CHAP
sent to the client. When the client endpoint (Peer) or PAP) was successful.
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) 4.2.6. AuthEapReqExt and AuthEapRespExt classes
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 EAP messages are embedded in COPS by sending an instance of the
The Response is calculated by the client and forwarded by authEapReqExt or authEapRespExt table, which each have an attribute
the PEP to the PDP. (Specific) to encapsulate the appropriate EAP messages necessary for
the authentication mechanism. 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
instances that it sends in Decision messages and the PEP generates
authEapRespExt instances that it sends in Report messages. Since
neither the PEP nor the PDP needs to maintain the messages
permanently, the same instance of each class is used when more than
one exchange is required in each direction.
4.11.3. AuthPapExt class Since both AuthEapReqExt and AuthEapRespExt are extensions of the
AuthExt class, they both inherit the attributes of AuthExt.
The AuthPapExt class extends the UserAuthExt class. It contains the AuthEapReXXExt table attributes Attribute type
PAP Password. (See sec. 3.2.) ------------------------------- --------------
authExtId InstanceId
authExtEvent ReferenceId
authEapReXXExtSpecific OCTET STRING
The attributes that this class adds to the base class are: Figure 4.4: Data elements in AuthEapReqExt and AuthEapRespExt tables
AuthPapExtPwd (Octet String) The AuthEapReXXExt class contains three attributes. The instanceId
A one-time password used to authenticate the client is used to uniquely define the instance in the table. However, since
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
message is transient instances of these tables are temporary and
should not be referred to. The Event attribute points to the Event
table entry for which EAP is being negotiated. The format of EAP
packages being passed by the AuthEapReXXExt classes is described in
[EAP].
4.11.4. AuthExtResult class 4.2.7. AuthPapExtEntry class
The AuthExtResult class extends the AuthExt class. It contains the The PAP information is embedded in the PEP Event Message by sending
Authentication result Boolean flag. an instance of the authPapExt table. Since the authPapExt table is
an extension of the userAuthExt table, which is an extansion of the
authExt table, the authPapExt inherits the attributes of these
tables.
The attributes that this class adds to the base class are: AuthPapExt table attributes Attribute type
--------------------------- --------------
authExtId InstanceId
authExtEvent ReferenceId
authRealm OCTET STRING
authUsername OCTET STRING
authPapExtPwd OCTET STRING
AuthExtSuccessful (TruthValue) Figure 4.5: Atributes of the AuthPapExt table.
A Boolean flag set to true if the authentication (via CHAP
or PAP) was successful.
4.11.5. AuthEapReqExt class The AuthPapExt contains five attributes. The instanceId is used to
uniquely define the instance in the table. However, since the PAP
password is sent to the PDP once and is needed by neither the PDP
nor the PEP after the client is authenticated, the instance should
not be referenced after it is used the first time. The Event
attribute points to the Event table entry for which PAP is being
negotiated.
The AuthEapReqExt class extends the AuthExt class. It contains an The result of the authentication for PAP is sent in the
EAP message. (See sec. 3.1.) Instances of this class are sent by the AuthExtResult table. Since the authExtResult table is an extension
PDP to the PEP. of the AuthExt table, it inherits the attributes of AuthExt.
The attributes that this class adds to the base class are: AuthExtResult table attributes Attribute type
------------------------------ --------------
authExtId InstanceId
authExtEvent ReferenceId
authExtAuthSuccess Truth Value
AuthEapReqExtSpecific (Octet String) Figure 4.6: Atributes of the AuthExtResult table.
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 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.
The AuthEapRespExt class extends the AuthExt class. It contains an 4.2.8. AuthChapExtEntry class
EAP message. (See sec. 3.1.) Instances of this class are sent by the
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 extansion of the
authExt table, the authChapExt table inherits the attributes of
these tables.
AuthChapExt table attributes Attribute type
---------------------------- --------------
authExtId InstanceId
authExtEvent ReferenceId
authRealm OCTET STRING
authUsername OCTET STRING
authChapExtId Unsigned32
authChapExtChal OCTET STRING
authChapExtResp OCTET STRING
Figure 4.7: Data elements of the AuthChapExtEntry datastructure.
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.
The AuthChapExtEntry contains seven attributes. The instanceId is
used to uniquely define the instance in the table. However, since
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
instance should not be referenced after it is used the first time.
The Event attribute points to the Event table entry for which PAP is
being negotiated.
The authChapExtChal attribute 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 authChapExtResp is calculated by the client and forwarded by the
PEP to the PDP. PEP to the PDP.
The attributes that this class adds to the base class are: 5. Signal Handling
AuthEapRespExtSpecific (Octet String) 5.1 Functional Description
An EAP message [EAP] passed from the client to the PDP via
the PEP in a COPS-PR Report message.
5. Message Types 5.2 Data Description
6. Programmatic Interface Between Signal and Event Handling
The programmatic interface between signal and event handling (Access
Bind API) allows flexible implementation of signal handling
mechanisms loosely coupled to the event handling capability provided
by the Access Bind. This flexibility allows multiple different
types of signaling technology be used and integrated using Access
Bind.
6.1. Functional Description
The Access Bind API consist of multiple phases of operation:
The notification and specification of Event Handling needs by the
signal handling mechanism. We call this signal handling
Registration with event handling.
The result of the Registration indicated by event handling of Access
Bind.
The indication by signal handling for event generation.
The indication of event result by event handling.
Signal handling state information notification.
Registration session termination.
Each of the above phases uses PRCs defined in the Access Bind
Framework PIB and COPS-PR functionality.
When the signaling mechanism initializes or realize it requires
event handling assistance, it shall register with event handling
using the EventHdlrReg() method. This acts as an indication to
event handling what services signal handling need and can also
indicate the capability of signal handling if necessary. These
service requirement and capability are indicated using PRC
definitions. Event handling uses these requirement and signal
handling capability, together with event handling capability to
generate the initial COPS REQ message that carry instances of the
capability and limitation PRC as they are defined in [FRWKPIB].
The Registration result is generated based on the COPS DEC message
received by event handling. This sets up and creates corresponding
entries in eventHandlerTable, eventHdlrElementTable,
eventHdlrEventScopeTable, eventHdlrHandleScopeTable, and
contextDataTable. Some of the content of these entries may be from
information provided by signal handling during registration. Event
handling shall use EventHdlrRegRsp() to provide the registration
result to signal handling. The amount of information included in
with the registration result is based on the functionality of the
signal handling mechanism and may include provisioning information
for the signal handling mechanism.
After the registration is completed, the event handling is ready for
event requests from signal handling. This is provided by the
EventGenReq() method. The signal handling mechanism must provide
the corresponding information necessary for the event generation.
This includes, in the form of PRIs, information necessary for event
handling and PDP to determine the event result. This may include
information on what the event result signal handling is expecting
for the specific event. The EventGenReq() shall cause event
handling to create an entry in eventTable and send a COPS REQ
message. Signal handling also have the responsibility for
indicating how the COPS Request Handles are used and re-used for
specific EventGenReq() invocation.
Upon receive of COPS DEC message from PDP, event handling uses
EventRslt() to communicate to signal handling the event result. The
result can be as simple as a yes/no response or as complex as
indicating in detail everything signal handling need to do to
process the event result. The degree of complexity is determined by
the signal handling mechanism. Event handling and this API in
Access Bind are flexible to handle this spectrum of complexity. The
event result can also affect event handling for integration of the
dynamic nature of event and the possibly more static setup of data
path usage.
Signal handling is required to indicate to event handling its
response for accepting/implementing the event result by using the
EventStateUpd() method. This information provided by signal
handling is again dependent on the signal handling mechanism and can
be simple or complex. The EventStateUpd() method is also used by
signal handling to indicate any asynchronous state changes or usage
indications.
When either signal handling or event handling wants to end the event
handler session registration, the EventHdlrRegTerm() method is used.
6.2. Method Description
EventHdlrReg(), called by signal handling
Indicates to event handling the services needed by signal
handling.
Parameters may include:
Signal Handling Type (COPS Client-Type).
Signal Handling Capability/Limitation (as PIB PRCs).
EventHdlrRegRsp(), called by event handling
Indicates the success/failure of the registration. For
successful registration, may provision the signal handler for
event generation and other signal handling tasks.
Parameters may include:
Registration Success/Failure
Signal handler provisioning PRCs
EventGenReq(), called by signal handling.
Event generation request. Used to request for service from
event handling. Triggers the sending of COPS REQ message to
PDP.
Parameters may include:
EventState, indicate create new or reuse existing event
state (COPS Handle). When reuse, ID for existing event
state.
AssociationInfo, the association for this event state.
This can be interface or service identification.
SignalInfo, the signal handling specific information. The
signaling information needed for correct event handling.
EventRslt(), called by event handling Event result.
Containing the information in a COPS DEC message for handling
the event.
Parameters may include:
EventState, indicate for which event state (COPS Handle)
this result is for.
ResultInfo, contains signal handling specific information.
EventStateUpd(), called by signal handling
For Event State update due to signal handling info changes,
including to indicate the Event Result have been implemented.
This may also be used for usage feedback purposes. This
triggers the generation of COPS Report message.
Parameters may include:
EventState, indicate for which event state (COPS Handle)
this update is for.
UpdateInfo, the state information being updated.
EventStateTerm(), called by either signal or event handling
Event state termination.
Removes the event state.
Parameters may include:
EventState, indicate which event state to terminate.
TermInfo, the termination information, e.g. reason code.
EventHdlrRegTerm(), called by either signal or event handling
Registration termination.
Ends the current registration.
6.3. Access Bind API Example
As an example, using RSVP as the signaling protocol for an unicast
flow between sender S1 and receiver R1 through a RSVP and Policy
aware router as in Figure 6.1.
+-----------------+
| |
| PDP |
| |
+--------+--------+
|
|
+--------+--------+
| PEP |
+-----------------+
| |
R1 ------------+if1 RSVP if2+------------ S1
| |
+-----------------+
Figure 6.1: Signal/Event Handling API _ RSVP Example
When the signaling protocol is RSVP, the API is used as follows:
1. EventHdlrReg() called by Signal Handling
RSVP Signal Handling indicates to the generic Event Handling
its need to communicate to the PDP via COPS-PR.
This will have Event Handling generate:
COPS REQ msg containing PRCs:
Framework PIB Capability/Limitation PRC for
- Event Handler (eventHandler/HdlrElement/etc)
- Signal Handler specific trigger filters
- Signal Handler provisioning PRCs
That indicate what signal handling needs from PDP
2. EventHdlrRegRsp() called by Event Handling
Indication of success/failure of Event Handler initialization.
This is caused by the event handler receiving:
A COPS DEC msg, and may include instances of PRCs that:
- Provisions the Signal Handler for event generation.
(i.e. eventHandler/HdlrElement/HdlrEventScope and RSVP
Filter PRC instances)
- Provisions the Signal Handler if supported.
(i.e. enable RSVP multicast, refresh timers)
3. EventGenReq() called by Signal Handling
Event Generation Request.
For RSVP, this is used as indication of PSB or RSB state
changes, when receiving or about to send RSVP messages,
requiring Policy Decisions.
Parameters:
EventState, indicate create new or reuse existing event
state (COPS Handle). When reuse, ID for existing event
state.
AssociationInfo, the association for this event state. For
RSVP this is the In/Out Interface identification.
SignalInfo, the signal handling specific information. For
RSVP, this contains PRCs for In/Out/Allocate Context,
Path/ResV/PathErr/ResVErr signal message type, and the
RSVP objects themselves (as carried by the COPS-RSVP
ClientSI).
This causes the sending of a COPS REQ message.
4. EventRslt() called by Event Handling
Event Result.
For RSVP, this is the decision from the PDP for a previously
generated event.
Parameters:
EventState, indicate for which event state (COPS Handle)
this result is for.
ResultInfo, contains the signal handling specific
information. For RSVP, this contains PRCs for
In/Out/Allocate Context, Path/ResV/PathErr/ResVErr signal
message type, and the RSVP objects themselves (as carried
by the COPS-RSVP ClientSI).
5. EventStateUpd() called by Signal Handling
For Event State update due to signal handling info changes. To
indicate the Event Result have been implemented.
For RSVP, this is used for generating the COPS Report message.
Parameters:
EventState, indicate for which event state (COPS Handle)
this update is for.
UpdateInfo, the state information being updated. For RSVP,
used to indicate report type.
6. EventTerm() called by either Signal or Event Handling
Event Terminiation.
Removes the Event State.
Parameters:
EventState, indicate which event state is to be terminated.
TermInfo, termination information. For RSVP, reason code.
7. 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 sending a provisioning decision to the PEP and the PIBs have the PDP sending a provisioning decision to the PEP and the
PEP responding with a success or fail. This PIB uses this paradigm PEP responding with a success or fail. This PIB uses this paradigm
in some cases, but it also uses a paradigm where the PEP initiates in some cases, but it also uses a paradigm where the PEP initiates
an event and the PDP responds with a success or fail. The specific an event and the PDP responds with a success or fail. The specific
use of this paradigm is with the PEP Access Event Message, which is use of this paradigm is with the PEP Access Event Message, which is
triggered by a PEP event and requires authentication success or triggered by a PEP event and requires authentication success or
failure semantics as part of the Provisioning Decision. This section failure semantics as part of the Provisioning Decision. This section
discusses both paradigms and how the various classes defined in discusses both paradigms and how the various classes defined in
Section 4 are combined to form the various message interactions sections 3 and 4 are combined to form the various message
described in sections 2 and 3. interactions described in sections 2, 3 and 4.
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,
and the class instances typically found in the message. and the class instances typically found in the message.
5.1. Event Handler Provisioning Decisions 7.1. Event Handler Provisioning Decisions
The Event Handler Provisioning Decision message is a COPS-PR The Event Handler Provisioning Decision message is a COPS-PR
Decision message used by the PDP to provision each Event Handler in Decision message used by the PDP to provision each Event Handler in
the PEP. It is likely to be a piece of a larger Decision message the PEP. It is likely to be a piece of a larger Decision message
that provisions other data path components that occur either before that provisions other data path components that occur either before
or after the Event Handler in the data path. However, it could also or after the Event Handler in the data path. However, it could also
be sent as a part of unrelated data path or other provisioning be sent as a part of unrelated data path or other provisioning
components. Event Handler provisioning typically includes the components. Event Handler provisioning typically includes the
EventHandler class, the EventHdlrElement class, the EventHandler class, the EventHdlrElement class, the
EventHdlrEventScope class, often the EventHdlrHandleScope class and EventHdlrEventScope class, often the EventHdlrHandleScope class and
the ContextData class. An optional set of EventHdlrAuthProtocol the ContextData class. An optional set of EventHdlrAuthProtocol
class instances may be sent if a DataPathEventHandler is set up for class instances may be sent if an IdentityEventHdlr object is set up
Access Event Messages. for Access Event Messages.
Because the EventHdlrElement, ContextData, EventHdlrEventScope, and Because the EventHdlrElement, ContextData, EventHdlrEventScope, and
the EventHdlrHandleScope classes all describe configuration details the EventHdlrHandleScope classes all describe configuration details
of the EventHandler, any of these class instances may be shared by of the EventHandler, any of these class instances may be shared by
multiple EventHandler instances. Therefore, in many cases, an multiple EventHandler instances. Therefore, in many cases, an
EventHandler Provisioning Decision will contain only an EventHandler EventHandler Provisioning Decision will contain only an EventHandler
that references instances of the other classes defined in previous that references instances of the other classes defined in previous
Provisioning Decisions. In addition, these classes can also be Provisioning Decisions. In addition, these classes can also be
provisioned individually in anticipation of being applied to an provisioned individually in anticipation of being applied to an
EventHandler. However, because there is a relationship between the EventHandler. However, because there is a relationship between the
EventHandler and EventHdlrElement classes, there is an order EventHandler and EventHdlrElement classes, there is an order
dependency between the classes. For instance, an EventHdlrEventScope dependency between the classes. For instance, an EventHdlrEventScope
must be provisioned at the same time or before an EventHdlrElement must be provisioned at the same time or before an EventHdlrElement
making use of the EventHdlrEventScope. EventHdlrElement,ContextData making use of the EventHdlrEventScope. EventHdlrElement,ContextData
and data path class instances referenced by an EventHandler must be and data path class instances referenced by an EventHandler must be
provisioned at the same time or before the EventHandler is provisioned at the same time or before the EventHandler is
provisioned. provisioned.
When the PEP receives an EventHandler Provisioning Decision, it must When the PEP receives an EventHandler Provisioning Decision, it MUST
always respond with a Provisioning Report indicating success or always respond with a Provisioning Report indicating success or
failure. failure.
Note that additional EventHdlrElements can simply be added to an Note that additional EventHdlrElements can simply be added to an
existing EventHandler by using the TagId (group identifier) for the existing EventHandler by using the TagId (group identifier) for the
EventHandler to which the element is to be added. Additional EventHandler to which the element is to be added. Additional
EventHdlrEventScope or EventHdlrHandleScope instances can be added EventHdlrEventScope or EventHdlrHandleScope instances can be added
similarly by adding PRIs with the TagId value of the group these similarly by adding PRIs with the TagId value of the group these
instances are to be added to. This allows incremental updates to be instances are to be added to. This allows incremental updates to be
made to the Event Handlers. made to the Event Handlers.
5.2. Provisioning Decision 7.2. Provisioning Report
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 7.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 that subsequent Provisioning Decisions occur with a smaller possible that subsequent Provisioning Decisions occur with a 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 Event Message 7.3. PEP Event Message
A PEP Event Message 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 Event Handler. This class of traffic has been identified by the Event Handler. This
Event Message possibly uses a new COPS Request Handle. The decision Event Message possibly uses a new COPS Request Handle. The decision
to use a new COPS Request Handle or reuse an existing Handle is to use a new COPS Request Handle or reuse an existing Handle is
based on the EventHdlrHandleScope information configured in the based on the EventHdlrHandleScope information configured in the
Event Handler. The Handle Scope information is a set of criteria Event Handler. The Handle Scope information is a set of criteria
that is protocol specific, and specifies the set of fields in the that is protocol specific, and specifies the set of fields in the
protocol that the Event Handler is sensitive towards. The PEP Event protocol that the Event Handler is sensitive towards. The PEP Event
Message is essentially a COPS-PR Request message. The PEP Event Message is essentially a COPS-PR Request message. The PEP Event
Message will always include an instance of the Event class. This Message MUST always include an instance of the Event class. This
Event instance references which EventHandlerElement instance and Event instance references the EventHandlerElement instance and
EventHandler instance caught the event. This tells the PDP what EventHandler instance that caught the event. This allows the PDP to
events belong to which Event Handler. Other Classes that may be a identify events belonging to each Event Handler. Other Classes that
part of a PEP Event Message include one or more instances of may be a part of a PEP Event Message include one or more instances
protocol specific Header Context Data and Interface data classes and of protocol specific Context Data and Interface data classes and
optionally an instance of one of the Authentication Extension optionally an instance of one of the Authentication Extension
classes (for example, if the Event is an access event). 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 Event determined by the PEP prior to generating the PEP Access Event
Message. EAP is an exception to this rule because EAP assumes a Message. EAP is an exception to this rule because EAP assumes a
direct negotiation between the Endpoint and the Authentication direct negotiation between the Endpoint and the Authentication
server. For EAP, it is assumed that the Endpoint generates a server. For EAP, it is assumed that the Endpoint generates a
response to the EAP Identity Request message before the PEP sends response to the EAP Identity Request message before the PEP sends
the Access Event Message. This allows the PEP to fill in the the Access Event Message. This allows the PEP to fill in the
Username and Realm in the UserAuthExt table. However, for this Username and Realm in the UserAuthExt table. However, for this
scenario, it is also assumed that the PEP Access Event Message will scenario, it is also assumed that the PEP Access Event Message will
include the EAP Identity Response in the authEapRespExtSpecific include the EAP Identity Response in the authEapRespExtSpecific
attribute of the AuthEapRespExtEntry class. Subsequent EAP attribute of the AuthEapRespExtEntry class. Subsequent EAP
negotiation will be performed with the Opaque Decision and Opaque negotiation will be performed with the Opaque Decision and Opaque
Report message types. When the negotiation is complete the PDP send Report message types. When the negotiation is complete the PDP sends
a Provisioning Decision message (that includes an instance of the a Provisioning Decision message (that includes an instance of the
AuthExtResult class specifying success or failure). Note that all AuthExtResult class specifying success or failure). Note that all
interactions resulting from a given Event Message (including interactions resulting from a given Event Message (including
authentication negotiation) is performed within the context of a authentication negotiation) are performed within the context of a
single COPS Request Handle. The COPS Request Handle provides an single COPS Request Handle. The COPS Request Handle provides an
independent dialog between the PDP and the PEP to fully process an independent dialog between the PDP and the PEP to fully process an
Access Event Message in a synchronous way. Access Event Message in a synchronous way.
5.4. PDP Provisioning Decision 7.3. PDP Provisioning Decision
When the PDP has all the necessary information to determine what When the PDP has all the necessary information to determine what
policies to provision for the event that was generated by the PEP, policies to provision for the event that was generated by the PEP,
and it has completed any intermediate data path provisioning that and it has completed any intermediate data path provisioning that
the event may be dependent on, the PDP will generate a PDP the event may be dependent on, the PDP SHOULD generate a PDP
Provisioning Decision message. The PDP Provisioning Decision message Provisioning Decision message. The PDP Provisioning Decision message
only contains the instances of the classes the PDP wants to only contains the instances of the classes the PDP wants to
configure as a result of the event. In addition to this message the configure as a result of the event. In addition to this message the
PDP may also send unsolicited Provisioning responses on other COPS PDP MAY also send unsolicited Provisioning responses on other COPS
handles to add policies that may be shared across events. 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 the
lifetime of a COPS Request handle is always controlled by the PEP. lifetime of a COPS Request handle is always controlled by the PEP.
The PDP may advise the PEP that the Handle is no longer valid via a The PDP MAY advise the PEP that the Handle is no longer valid via a
provisioning update. However, the ultimate dispensation of the provisioning update. However, the ultimate dispensation of the
Request Handle and the associated tables are always determined by Request Handle and the associated tables are always determined by
the PEP. The PDP can also indicate that a traffic flow may no longer the PEP. The PDP MAY also indicate that a traffic flow may no longer
have access to resources by changing the data path to drop packets have access to resources by changing the data path to drop packets
arriving for that traffic flow. Since the PDP can modify the data arriving for that traffic flow. Since the PDP can modify the data
path such that all packets for the flow will be dropped, both path such that all packets for the flow will be dropped, both
alternatives achieve the same semantics. The PEP can delete the COPS alternatives achieve the same semantics. Since a COPS-PR
Request Handle simply by notifying the PDP via a Delete Request Provisioning Decision is used, the PEP MUST send a report back to
Message that the provisioned policies for that Handle are no longer the PDP to confirm that there are no problems with the data path
valid. Since a COPS-PR Provisioning Decision is used, the PEP must change requested by the PDP.
send a report back to the PDP to confirm that there are no problems
with the data path change requested by the PDP.
When a COPS Request Handle is removed all contained class instances The PEP MAY delete the COPS Request Handle simply by notifying the
must be removed as well. Typically these will include header and PDP via a Delete Request Message that the provisioned policies for
that Handle are no longer valid.
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. authentication table instances.
5.5. PDP fetching Event-specific ContextData 7.4. PDP fetching Event-specific ContextData
The ContextData class can be specified either during the The ContextData class MAY be specified either during the
configuration of the EventHandler to indicate what context data configuration of the EventHandler to indicate what context data
should be sent with each PEP Event Message or it can be used by the should be sent with each PEP Event Message or it MAY be used by the
PDP to get additional context data for an event after it receives a PDP to get additional context data for an event after it receives an
Event Message. In the latter case, the PDP may send a solicited Event Message. In the latter case, the PDP MAY send a solicited
response that specifies ContextData for the last Event Message decision that specifies ContextData for the last Event Message
received on the same Request Handle. The ContextData message received on the same Request Handle. The ContextData message
contains PRC names to retrieve the specific information needed to contains PRC names to retrieve the specific information. This
either authorize a pending event, monitor a set of policies bound to information may be needed to either authorize a pending event,
the handle or get more context information regarding the event. monitor a set of policies bound to the handle or get more context
Since each ContextData class only retrieves a specific subset of the information regarding the event. Since each ContextData class only
information regarding the event within the context of a Request retrieves a specific subset of the information regarding the event
Handle, a single request message can contain multiple instances of within the context of a Request Handle, a single request message MAY
the ContextData class, thereby supporting the retrieval of as much contain multiple instances of the ContextData class, thereby
event-specific information as needed in a single message. supporting the retrieval of as much event-specific information as
needed in a single message.
The COPS-PR message type used to fetch Event-specific ContextData is The COPS-PR message type used by the PDP to fetch Event-specific
a Provisioning Decision message. The ContextData class instances are ContextData is a Provisioning Decision message. When the PEP
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 receives a message from the PDP asking for Event-specific
ContextData, it will send an Event-specific ContextData message in a ContextData, it MUST send an Event-specific ContextData message in a
COPS Request message back to the PDP. COPS Request message back to the PDP. This request message MUST use
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.
The updated Event-specific ContextData Request from the PEP will The updated Event-specific ContextData Request from the PEP SHOULD
contain a set of Header and Interface context data class instances. contain a set of Header and Interface context data class instances.
Since the updated request uses the same Request Handle the PDP knows Since the updated request uses the same Request Handle, the PDP
which event is being updated by more context data. Using PDP Fetched knows which event is being updated by more context data. Using PDP
ContextData messages precludes the PDP from provisioning the PEP to Fetched ContextData messages precludes the PDP from provisioning the
allow multiple simultaneous Event Messages outstanding on the same PEP to allow multiple simultaneous Event Messages outstanding on the
Handle. same Handle.
5.6. Event-specific ContextData Response 7.5. Event-specific ContextData Response
The Event-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 Event table instances. However, because Reference Identifiers to the Event table
are not specified in the header or interface data tables, a Report are not specified in the header or interface data tables, a Report
message may contain header and interface data for one and only one message may contain header and interface data for one and only one
Event or the most recent Event Message received on that specific Event or the most recent Event Message received on that specific
COPS Request Handle. COPS Request Handle.
5.7. Opaque Decision 7.6. 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 via authEapReqExt table instances.
authEapReqExt table instances.
5.8. Opaque Report 7.7. 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 via
in this message is used to send authEapRespExt table instances. authEapRespExt table instances.
6. Combining Data Structures in Messages 7.8. Combining Data Structures in Messages
In the most degenerate case, the PDP provisions the EventHandler to In the most degenerate case, the PDP provisions the EventHandler to
only send the Event object when an event occurs. The PDP then only send the Event object when an event occurs. The PDP then
requests Event-specific Context Data that the PEP will respond to requests Event-specific Context Data that the PEP will respond to
with Report Message. In addition, if EAP authentication is required, with a Report Message. In addition, if EAP authentication is
a sequence of Opaque Decisions and Opaque Reports are also required. required, a sequence of Opaque Decisions and Opaque Reports are also
Finally, if new data paths need to be provisioned (including required. Finally, if new data paths need to be provisioned
specialized EventHandlers), normal Provisioning Decision and Report (including specialized EventHandlers), normal Provisioning Decision
messages must also be exchanged. Note that these provisioning and Report messages must also be exchanged. Note that these
decisions may be on separate COPS Request Handles. provisioning decisions may be on separate COPS Request Handles.
In some environments, for example authorization, it is essential to In some environments, for example authorization, it is essential to
complete the transaction as quickly as possible. The way to complete the transaction as quickly as possible. The way to
accelerate this process is to combine as many messages into a single accelerate this process is to combine as many messages into a single
message as possible. This section describes which messages can be message as possible.
collapsed, and what the rules are for collapsing the messages.
6.1. Combining Context Data in Event 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.
7. Access Bind Usage Examples 8. Access Bind Usage Examples
Following examples on how the Access Bind PIB PRCs are used provide Following examples on how the Access Bind PIB PRCs are used provide
some additional clarifications on the PRC definitions. But they by some additional clarifications on the PRC definitions. But they by
no means indicate all the PRCs needed for the application given by no means indicate all the PRCs needed for the application given by
the example. And providing these examples here does not indicate the example. And providing these examples here does not indicate
where the application specific PRCs should be defined. These where the application specific PRCs should be defined. These
examples are provided only to assist better and easier understanding examples are provided only to assist better and easier understanding
of the Access Bind PIB. of the Access Bind PIB.
7.1 Wireless LAN (802.11 Access Point) Usage Example 8.1 Wireless LAN (802.11 Access Point) Usage Example
A wireless LAN Access Point (AP) is pictured in Figure 7.1 below. A wireless LAN Access Point (AP) is pictured in Figure 7.1.1 below.
This is based roughly on 802.11/802.1x concepts. The following is This is based roughly on 802.11/802.1x concepts. The following is
meant to give an indication of how the Access Bind PIB could be meant to give an indication of how the Access Bind PIB could be
included in such an AP. Note that this is an exercise to see if the included in such an AP. Note that this is an exercise to see if the
concepts fit together, not a proposal for exactly how they would concepts fit together, not a proposal for exactly how they would
fit. fit.
The AP shown below includes a æService ManagerÆ (SM), which The AP shown below includes a _Service Manager_ (SM), which
interfaces with the wireless data interface. For incoming wireless interfaces with the wireless data interface. For incoming wireless
data it separates management frames and level 2 frames. In the data it separates management frames and level 2 frames. In the
following we will deal particularly with Associate and ReAssociate following we will deal particularly with Associate and ReAssociate
Management Frames. Management Frames.
The SM (as interpreted here) takes Associate and Reassociate The SM (as interpreted here) takes Associate and Reassociate
management frames and creates a temporary Port Access Entity PAE for management frames and creates a temporary Port Access Entity PAE for
the association. The PAE must then be authenticated and provisioned the association. The PAE must then be authenticated and provisioned
by an external Authentication Server (AS). Communication with the by an external Authentication Server (AS). Communication with the
AS is assumed in this model to be mediated by a Policy Enforcement 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 Point (PEP, which is part of the AP. The AS acts as a Policy
Decision Point (PDP). Decision Point (PDP).
oooooooooo Ethernet Port 8.1.1 Wireless LAN Access Event Handler Provisioning
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 In a Access PIB implementation the figure shows the SM sending a REQ
sending a REQ at boot time to tell the AS that it is up and what at boot time to tell the AS that it is up and what capabilities it
capabilities it has. The PDP returns a configuration to support the has. The PDP returns a configuration to support the SM. In
SM. In particular, this configuration includes provisioning particular, this configuration includes provisioning information for
information for how to instantiate a PAE and what trigger how to instantiate a PAE and what trigger information should be sent
information should be sent by the instantiated PAE to the PDP. by the instantiated PAE to the PDP.
The provisioning of the Event Handler is supported by the Access The Event Handler Provisioning is supported by the Access Bind PIB
Bind PIB by using the following PRCs in the decision (DEC) message: by using the following PRCs in the decision (DEC) message:
- eventHandler - eventHandler
- eventhdlrElement - eventhdlrElement
- eventhdlrEventScope - eventhdlrEventScope
With eventhdlrEventScopeFilter indicating how the signaling protocol With eventhdlrEventScopeFilter indicating how the signaling protocol
is recognized. is recognized.
7.1.2 Wireless LAN Access Event Handling 8.1.2 Wireless LAN Access Event Handling
When an event (here a Associate or ReAssociate) is detected the When an event (here a Associate or ReAssociate) is detected the
SM/event handler instantiates and initializes a PAE. The initial SM/event handler instantiates and initializes a PAE. The initial
PAE instance includes an access port which splits internally into a PAE instance includes an access port which splits internally into a
controlled and uncontrolled port. controlled and uncontrolled port.
The controlled port is what is used to pass data from the access 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 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 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 flow. It may also have QoS parameters that can be controlled by the
AS. In its initial state the controlled port drops all incoming AS. In its initial state the controlled port drops all incoming
frames. frames.
The uncontrolled port connects to an internal authenticator. The The uncontrolled port connects to an internal authenticator. The
authenticator creates the initial trigger. In some cases it may authenticator creates the initial trigger. In some cases it may
need to send an EAP frame back to the Station prior to sending the 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 initial trigger, and other times it may have enough information from
the initial Associate or ReAssociate to create the trigger the initial Associate or ReAssociate to create the trigger
immediately. immediately.
The Event handling is supported by the Access Bind PIB. The Access Event Handling is supported by the Access Bind PIB.
The PEP creates an instance of event PRC, with eventEventhdlr The PEP creates an instance of event PRC, with eventEventhdlr
referencing the eventHandler, and eventCause referencing referencing the eventHandler, and eventCasue referencing
eventhdlrElement provisioned in Access Event Handler Provisioning eventhdlrElement provisioned in Access Event Handler Provisioning
above. above.
This event PRI will be sent by the PEP to the PDP in a REQ using a 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 new COPS Request Handle. This REQ message may contain additional
PRIs as dictated by how a specific signaling protocol should be PRIs as dictated by how a specific signaling protocol should be
handled. handled.
7.1.3 Wireless LAN Access Event Decision 8.1.3 Wireless LAN Access Event Decision
The AS/PDP decides whether the trigger contains enough information The AS/PDP decides whether the trigger contains enough information
to make an authentication decision. If not, it may initiate an EAP to make an authentication decision. If not, it may initiate an EAP
dialog through the authenticator to the STATION. dialog through the authenticatior to the STATION.
Once it has enough information the PDP makes a decision and sends a Once it has enough information the PDP makes a decision and sends a
Provisioning message to the AP that sets QoS parameters and æclosesÆ Provisioning message to the AP that sets QoS parameters and _closes_
the switch on the controlled port. Since the controlled and the switch on the controlled port.
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 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 the same COPS Request Handle created in Access Event Handling above.
Access Event. The content (PRCs) carried by the DEC message will The content (PRCs) carried by the DEC message will depend on the
depend on the functionality need to be provided. It may be command functionality need to be provided. It may be command to _close_ the
to æcloseÆ the switch on the controlled port, it may contain QoS switch on the controlled port, it may contain QoS parameters. This
parameters. step is very similar to, if not the same as, provisioning using the
DiffServ PIB.
7.2 RSVP Usage Example 8.2 RSVP Usage Example
RSVP is a signaling protocol used for a variety of purposes RSVP is a signaling protocol used for a variety of purposes
including some call setup applications and MPLS label distribution including some call setup applications and MPLS label distribution
for traffic engineering. RSVP uses a number of message types to for traffic engineering. RSVP uses a number of message types to
negotiate both the hop-by-hop path and the service requirements negotiate both the hop-by-hop path and the service requirements
between a sender and one or more receivers. between a sender and one or more receivers.
Some RSVP messages contain information that helps determine whether Some RSVP messages contain information that helps determine whether
the reservation should be accepted or not. However, the router may the reservation should be accepted or not. However, the router may
not equipped with sufficient context to take advantage of the not equipped with sufficient context to take advantage of the
information in determining whether to accept or reject an RSVP information in determining whether to accept or reject an RSVP
skipping to change at page 50, line 4 skipping to change at line 2775
RSVP messages, a number of filter classes must be defined. These RSVP messages, a number of filter classes must be defined. These
filter classes are general purpose and could be used both by filter classes are general purpose and could be used both by
EventHandlers and by Classifiers although the semantics of the EventHandlers and by Classifiers although the semantics of the
filter class are somewhat different for each. The other group of filter class are somewhat different for each. The other group of
classes is the Context Data classes that pass some or all parts 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 the RSVP message to the PDP when the EventHandler generates an
event. event.
Because COPS assumes that all RSVP message objects are sent to the Because COPS assumes that all RSVP message objects are sent to the
PDP, each well known RSVP object will be assigned a unique Context PDP, each well known RSVP object will be assigned a unique Context
Data PRC identifier and the rest of the RSVP objectÆs attributes 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 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 original RSVP object. The actual PRC mappings for these objects can
be found in the PIB definition. For details on the operation of be found in the PIB definition. For details on the operation of
these objects refer to [RSVP] and [INTSERV]. In addition, a PIB these objects refer to [RSVP] and [INTSERV]. In addition, a PIB
class is also defined to support unrecognized RSVP objects. class is also defined to support unrecognized RSVP objects.
A Context Data PIB class is also specified to describe the relevant A Context Data PIB class is also specified to describe the relevant
RSVP common header attributes. The attributes in the common header RSVP common header attributes. The attributes in the common header
that will be specified are: that will be specified are:
1. The RSVP MsgType attribute, which distinguishes a PATH message 1. The RSVP MsgType attribute, which distinguishes a PATH message
skipping to change at page 50, line 29 skipping to change at line 2800
mechanism for determining whether non-RSVP hops have been mechanism for determining whether non-RSVP hops have been
traversed by comparing this field with the IP TTL field. traversed by comparing this field with the IP TTL field.
4. The In Interface (if known) 4. The In Interface (if known)
5. The Out Interface (if known) 5. The Out Interface (if known)
A special context data class, called AllRSVPMsgObjects, is defined A special context data class, called AllRSVPMsgObjects, is defined
to simplify the process of specifying the set of RSVP objects to be to simplify the process of specifying the set of RSVP objects to be
included with a COPS-PR Event message. Rather than explicitly included with a COPS-PR Event message. Rather than explicitly
specifying every context data class that should be included with the specifying every context data class that should be included with the
Event message, this class (when referenced by PRC through the Event message, this class (when referenced by PRC through the
ContextDataIfElement attribute of the ContextData class) indicates ContextDataIfElement attibute of the ContextData class) indicates
that all RSVP objects, including the common header class described that all RSVP objects, including the common header class described
above, should be encapsulated and propagated to the PDP. All Refresh above, should be encapsulated and propagated to the PDP. All Refresh
Reduction related RSVP objects (MESSAGE_ID, MESSAGE_ID_ACK, and Reduction related RSVP objects (MESSAGE_ID, MESSAGE_ID_ACK, and
MESSAGE_ID_NACK) are explicitly excluded from being sent to the PDP MESSAGE_ID_NACK) are explicitly excluded from being sent to the PDP
when the AllRSVPMessageObjects attribute is set to True. These when the AllRSVPMessageObjects attribute is set to True. These
objects are specifically for purpose of synchronizing state between objects are specifically for purpose of synchronizing state between
RSVP hops and bears no value in the policy decision process. RSVP hops and bears no value in the policy decision process.
However, a context data PIB object is defined for each of these However, a context data PIB object is defined for each of these
classes in the event that a PDP determines that it needs these classes in the event that a PDP determines that it needs these
objects. objects.
skipping to change at page 51, line 51 skipping to change at line 2874
are directed to the EventHandler by a classifier. In this scenario are directed to the EventHandler by a classifier. In this scenario
the EventHandler as behaving as a termination point for all RSVP the EventHandler as behaving as a termination point for all RSVP
messages. Hence, the EventHandler class is provisioned with no data messages. Hence, the EventHandler class is provisioned with no data
path elements following the EventHandler. Therefore, the attribute path elements following the EventHandler. Therefore, the attribute
eventhdlrNonMatchNext is left unassigned. eventhdlrNonMatchNext is left unassigned.
Alternatively, the EventHandler can also be provisioned such that Alternatively, the EventHandler can also be provisioned such that
RSVP and non-RSVP packets alike pass through the EventHandler, but RSVP and non-RSVP packets alike pass through the EventHandler, but
only RSVP messages invoke events. In this case, the attribute only RSVP messages invoke events. In this case, the attribute
eventhdlrNonMatchNext would specify the next data path element that eventhdlrNonMatchNext would specify the next data path element that
should process any packets not matching the EventHandlerÆs criteria should process any packets not matching the EventHandler's criteria
(non RSVP packets). (non RSVP packets).
The EventhdlrElement class identifies a specific category of events. The EventhdlrElement class identifies a specific category of events.
Suppose one wanted to generate different Events for PATH messages Suppose one wanted to generate different Events for PATH messages
and RESV messages. This could be done by configuring one and RESV messages. This could be done by configuring one
EventhdlrElement to only match PATH messages and another EventhdlrElement to only match PATH messages and another
EventhdlrElement to only match RESV messages. Event messages contain EventhdlrElement to only match RESV messages. Event messages contain
a reference to the EventhdlrElement that generated the event. a reference to the EventhdlrElement that generated the event.
Therefore, it is possible to generate different events from the same Therefore, it is possible to generate different events from the same
EventHandler. EventHandler.
skipping to change at page 53, line 37 skipping to change at line 2966
Irrespective of whether Refresh Reduction is in use or not, the RSVP Irrespective of whether Refresh Reduction is in use or not, the RSVP
daemon is responsible for aging out reservations that are no longer daemon is responsible for aging out reservations that are no longer
valid. As with traditional COPS, when a reservation is aged out, the valid. As with traditional COPS, when a reservation is aged out, the
RSVP daemon or other entity responsible for aging out reservations RSVP daemon or other entity responsible for aging out reservations
MUST take responsibility for deleting COPS Request Handles. This MUST take responsibility for deleting COPS Request Handles. This
allows the PDP to clean up state associated with the reservation and allows the PDP to clean up state associated with the reservation and
ensures the proper removal of any policies in the PEP specifically ensures the proper removal of any policies in the PEP specifically
assigned through the COPS Request Handle. assigned through the COPS Request Handle.
Figure 7.2 shows how the various Event Handler objects would be Figure 7.1 shows how the various Event Handler objects would be
provisioned in a router to ensure that an event is generated for provisioned in a router to ensure that an event is generated for
every RSVP message. every RSVP message.
+-------------------+ +-------------------+
|EventHandler | |EventHandler |
| Id=EH1 | | Id=EH1 |
| NonMatchNext=<NUL>| | NonMatchNext=<NUL>|
| ElementRef=(Elem1)| | ElementRef=(Elem1)|
+-------------+-----+ +-------------+-----+
| |
skipping to change at page 54, line 47 skipping to change at line 3012
| | Precedence=1| +-------------+ | Protocol=* | | | Precedence=1| +-------------+ | Protocol=* |
| +-------------+ | DestPort=* | | +-------------+ | DestPort=* |
| +------------+ | SrcIP=* | | +------------+ | SrcIP=* |
| +-------------+ +->|RsvpFilter | | SrcPort=* | +-------------+ +->|RsvpFilter | | SrcPort=*
| |HandleScope | | | Id=R2 | +------------+ | |HandleScope | | | Id=R2 | +------------+
+->| Id=Hd2 | | | DestIP=* | +->| Id=Hd2 | | | DestIP=* |
| Group=HD | | | Protocol=* | | Group=HD | | | Protocol=* |
| Filter=(R2)-+--+ | DestPort=* | | Filter=(R2)-+--+ | DestPort=* |
| Precedence=1| +------------+ | Precedence=1| +------------+
+-------------+ +-------------+
Fig 7.2: Representation of an Event Handler for RSVP Fig 8.1: Representation of an Event Handler for RSVP
Figure 7.2 represents the set of PIB classes that would be Figure 8.1 represents the set of PIB classes that would be
provisioned in order to indicate to the PEP that RSVP messages provisioned in order to indicate to the PEP that RSVP messages
should generate unique events for any combination of filters or should generate unique events for any combination of filters or
sessions. However, all messages using the same unique session will sessions. However, all messages using the same unique session will
share the same COPS Request Handle. share the same COPS Request Handle.
When an RSVP message arrives at the PEP with an new combination of When an RSVP message arrives at the PEP with an new combination of
session attribute values, the PEP will create a new COPS Request session attribute values, the PEP will create a new COPS Request
Handle. Following this, an Event message will be generated Handle. Following this, an Event message will be generated
containing an Event object with references to EventHandler EH1 and containing an Event object with references to EventHandler EH1 and
EventhdlrElement Elem1. These two pieces of information allow the EventhdlrElement Elem1. These two pieces of information allow the
skipping to change at page 55, line 17 skipping to change at line 3036
event type generated the event. In addition the Event message also event type generated the event. In addition the Event message also
contains a set of Context Data objects. Since the AllRSVPMsgObjects contains a set of Context Data objects. Since the AllRSVPMsgObjects
class was specified in the ContextData class, all RSVP objects are 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 encapsulated in COPS-PR PIB classes and sent to the PDP in the Event
message. message.
When the PDP receives the Event message, it determines what policies When the PDP receives the Event message, it determines what policies
to provision in the PEP. Suppose the RSVP message was a reservation to provision in the PEP. Suppose the RSVP message was a reservation
request for a controlled load service with a bandwidth allocation of request for a controlled load service with a bandwidth allocation of
1 Mbps and session object contained (SessionDestIP = 1.2.3.4, 1 Mbps and session object contained (SessionDestIP = 1.2.3.4,
SessionProtocol=UDP, SessionDestPort=7788). If the routerÆs SessionProtocol=UDP, SessionDestPort=7788). If the router's
implementation only supported 4 queues with respective bandwidth implementation only supported 4 queues with respective bandwidth
allocations of 20Mb, 40Mb, 30Mb, and 10Mb, the PDP may decide that allocations of 20Mb, 40Mb, 30Mb, and 10Mb, the PDP may decide that
allocating the reservation to queue 3 can satisfy the reservation allocating the reservation to queue 3 can satisfy the reservation
request. Hence, a PDP might generate a provisioning policy as a request. Hence, a PDP might generate a provisioning policy as a
result of the PEPÆs Event message that creates a new Classifier 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 Element and Filter that matches all 1.2.3.4:7788 traffic and directs
it to queue 3. it to queue 3.
8. The AccessBind PIB Module 9. The AccessBind PIB Module
--
-- 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, PrcIdentifierOid
FROM FRAMEWORK-TC-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 "200202202002Z" LAST-UPDATED "200202202002Z"
ORGANIZATION "IETF RAP WG" ORGANIZATION "IETF RAP WG"
skipping to change at page 56, line 41 skipping to change at line 3085
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 "A PIB module containing the set of classes to
configure generic event handlers, and outsource configure generic event handlers, and outsource
events as they occur. One application of this PIB is events as they occur. One application of this PIB is
to bind authorization and authentication to COPS to bind authorization and authentication to COPS
Provisioning." Provisioning."
::= { pib xxx } -- xxx to be assigned by IANA ::= { pib 4 } -- 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 } eventClasses OBJECT IDENTIFIER ::= { accessBindPib 1 }
eventClasses OBJECT IDENTIFIER ::= { accessBindPib 2 } eventHdlrClasses OBJECT IDENTIFIER ::= { accessBindPib 2 }
eventHdlrClasses OBJECT IDENTIFIER ::= { accessBindPib 3 } contextClasses OBJECT IDENTIFIER ::= { accessBindPib 3 }
contextClasses OBJECT IDENTIFIER ::= { accessBindPib 4 }
authClasses OBJECT IDENTIFIER ::= { accessBindPib 5 }
filterClasses OBJECT IDENTIFIER ::= { accessBindPib 6 }
-- --
-- Event Table -- Event Table
-- --
-- Instances of this table represent events that occurred at -- Instances of this table represent events that occurred at
-- the PEP. The events reference the event handler instance -- the PEP. The events reference the event handler instance
-- and the specific event handler element that the event was -- and the specific event handler element that the event was
-- caught by. -- caught by.
eventTable OBJECT-TYPE eventTable OBJECT-TYPE
SYNTAX SEQUENCE OF EventEntry SYNTAX SEQUENCE OF EventEntry
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. As a result of this event, The PDP may send to the PDP. As a result of this event, The PDP may send
additional unsolicited decisions to the PEP after additional unsolicited decisions to the PEP after
sending the mandatory solicited decision for the event." sending the mandatory solicited decision for the event."
skipping to change at page 58, line 40 skipping to change at line 3183
-- the event and specify the context data to send to the PDP -- the event and specify the context data to send to the PDP
-- when an event is caught. -- when an event is caught.
eventHandlerTable OBJECT-TYPE eventHandlerTable OBJECT-TYPE
SYNTAX SEQUENCE OF EventHandlerEntry SYNTAX SEQUENCE OF EventHandlerEntry
PIB-ACCESS install PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The eventHandlerTable specifies for what events the PEP "The eventHandlerTable specifies for what events the PEP
should send a request to the PDP. As a result of this should send a request to the PDP. As a result of this
request, the PEP may send configuration changes to the request, the PDP may send configuration changes to the
PEP. An instance of this class defines the circumstances PEP. An instance of this class defines the circumstances
for generating a request, and provides the means for for generating a request, and provides the means for
specifying the contents of the PEP Request. Hence, the specifying the contents of the PEP Request. Hence, the
eventHandlerTable can be said to create eventTable eventHandlerTable can be said to create eventTable
entries. " entries. "
::= { eventHdlrClasses 1 } ::= { eventHdlrClasses 1 }
eventHandlerEntry OBJECT-TYPE eventHandlerEntry OBJECT-TYPE
SYNTAX EventHandlerEntry SYNTAX EventHandlerEntry
skipping to change at page 59, line 34 skipping to change at line 3226
::= { eventHandlerEntry 1} ::= { eventHandlerEntry 1}
eventHandlerElements OBJECT-TYPE eventHandlerElements OBJECT-TYPE
SYNTAX TagReferenceId SYNTAX TagReferenceId
PIB-TAG { eventHdlrElementGrpId } PIB-TAG { eventHdlrElementGrpId }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A reference to a group of eventHdlrElement instances, "A reference to a group of eventHdlrElement instances,
each of which determines the scope (criteria for each of which determines the scope (criteria for
generating a new request) and what context information to generating a new request) and what context information
send in a request." to send in a request."
::= { eventHandlerEntry 2} ::= { eventHandlerEntry 2}
eventHandlerNonMatchNext OBJECT-TYPE eventHandlerNonMatchNext OBJECT-TYPE
SYNTAX Prid SYNTAX Prid
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The data path for 'out of scope' traffic." "The data path for 'out of scope' traffic."
::= { eventHandlerEntry 3} ::= { eventHandlerEntry 3}
skipping to change at page 62, line 50 skipping to change at line 3400
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." partitioning various portions of traffic."
::= { eventHdlrClasses 3 } ::= { eventHdlrClasses 3 }
eventHdlrEventScopeEntry OBJECT-TYPE eventHdlrEventScopeEntry OBJECT-TYPE
SYNTAX EventHdlrEventScopeEntry SYNTAX EventHdlrEventScopeEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An instance of this class defines an individual criterion "An instance of this class defines an individual
to be used towards generating an event." criterion to be used towards generating an event."
PIB-INDEX { eventHdlrEventScopeId } PIB-INDEX { eventHdlrEventScopeId }
UNIQUENESS { eventHdlrEventScopeGroup, UNIQUENESS { eventHdlrEventScopeGroup,
eventHdlrEventScopeFilter eventHdlrEventScopeFilter
} }
::= { eventHdlrEventScopeTable 1} ::= { eventHdlrEventScopeTable 1}
EventHdlrEventScopeEntry::= SEQUENCE { EventHdlrEventScopeEntry::= SEQUENCE {
eventHdlrEventScopeId InstanceId, eventHdlrEventScopeId InstanceId,
eventHdlrEventScopeGroup TagId, eventHdlrEventScopeGroup TagId,
eventHdlrEventScopeFilter Prid, eventHdlrEventScopeFilter Prid,
skipping to change at page 63, line 55 skipping to change at line 3457
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
eventHdlrEventScope class is the same, the attributes eventHdlrEventScope 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 with the following rules: single filter criteria with the following rules:
1. If the filters are not of the same type, the filters 1. If the filters are not of the same type, the filters
are ANDÆed as a whole eg (RSVP and IP) are AND'ed as a whole eg (RSVP and IP)
2. If the filter types are the same, the attribute values 2. If the filter types are the same, the attribute values
are ORÆed and the attributes themselves are ANDÆed, are OR'ed and the attributes themselves are AND'ed,
for example, two IP filters with src protocol values for example, two IP filters with src protocol values
56 and 57 respectively and dst protocol values 20 and 56 and 57 respectively and dst protocol values 20 and
25 , would be treated as the condition (src port (56 25 , would be treated as the condition (src port (56
or 57) AND dst port (20 or 25)." or 57) AND dst port (20 or 25)."
::= { eventHdlrEventScopeEntry 4} ::= { eventHdlrEventScopeEntry 4}
eventHdlrEventScopeChangeFlag OBJECT-TYPE eventHdlrEventScopeChangeFlag OBJECT-TYPE
SYNTAX TruthValue SYNTAX TruthValue
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Boolean value, if set to 'true' indicates that a new "Boolean value, if set to 'true' indicates that a new
event should be generated if any of the assigned fields in event should be generated if any of the assigned fields
the associated filter change." in the associated filter change."
::= { eventHdlrEventScopeEntry 5} ::= { eventHdlrEventScopeEntry 5}
-- --
-- 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.
eventHdlrHandleScopeTable OBJECT-TYPE
SYNTAX SEQUENCE OF EventHdlrHandleScopeEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"This class defines the criteria to be used for
deciding whether to create a new COPS RequestHandle for
an event or to use an existing Handle."
::= { eventHdlrClasses 4 }
eventHdlrHandleScopeEntry OBJECT-TYPE
SYNTAX EventHdlrHandleScopeEntry
STATUS current
DESCRIPTION
"An instance of this class defines an individual criterion
to be used towards deciding when to create a new Handle."
PIB-INDEX { eventHdlrHandleScopeId }
UNIQUENESS { eventHdlrHandleScopeGroup,
eventHdlrHandleScopeFilter
}
::= { eventHdlrHandleScopeTable 1}
EventHdlrHandleScopeEntry::= SEQUENCE {
eventHdlrHandleScopeId InstanceId,
eventHdlrHandleScopeGroup TagId,
eventHdlrHandleScopeFilter Prid,
eventHdlrHandleScopePrecedence INTEGER,
eventHdlrHandleScopeChangeFlag TruthValue
}
eventHdlrHandleScopeId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the eventHdlrHandleScopeTable class."
::= { eventHdlrHandleScopeEntry 1}
eventHdlrHandleScopeGroup OBJECT-TYPE
SYNTAX TagId -- corresponding TagReference
-- defined in eventHdlrElementEntry
STATUS current
DESCRIPTION
"Represents the binding between the eventHdlrElementEntry
and the eventHdlrHandleScope entries. A group of
eventHdlrHandleScope entries constitutes the criteria for
defining the scope of the Handles generated."
::= { eventHdlrHandleScopeEntry 2}
eventHdlrHandleScopeFilter OBJECT-TYPE
SYNTAX Prid
STATUS current
DESCRIPTION
"Pointer to a filter to be used as the criteria."
::= { eventHdlrHandleScopeEntry 3}
eventHdlrHandleScopePrecedence 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
eventHdlrHandleScope class is the same, the attributes
within all the instances are treated collectively as a
single filter criteria."
::= { 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}
--
-- 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.
eventHdlrAuthProtocolTable OBJECT-TYPE
SYNTAX SEQUENCE OF EventHdlrAuthProtocolEntry
PIB-ACCESS install
STATUS current
DESCRIPTION
"This class lists the authentication protocols that can
be used for an access request."
::= { eventHdlrClasses 5 }
eventHdlrAuthProtocolEntry OBJECT-TYPE
SYNTAX EventHdlrAuthProtocolEntry
STATUS current
DESCRIPTION
"An instance of this class describes an authentication
protocol that may be used for an access request. Instances
of this class that share the same TagId value collectively
constitute a list of authentication protocols that may be
used for a given access request"
PIB-INDEX { eventHdlrAuthProtocolId }
UNIQUENESS { eventHdlrAuthProtocolGroup,
eventHdlrAuthProtocolAuthMechanism
}
::= { eventHdlrAuthProtocolTable 1}
EventHdlrAuthProtocolEntry::= SEQUENCE {
eventHdlrAuthProtocolId InstanceId,
eventHdlrAuthProtocolGroup TagId,
eventHdlrAuthProtocolAuthMechanism INTEGER
}
eventHdlrAuthProtocolId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the ContextDataTable class."
::= { eventHdlrAuthProtocolEntry 1}
eventHdlrAuthProtocolGroup OBJECT-TYPE
SYNTAX TagId -- corresponding TagReference
-- in datapathEventHdlrEntry
STATUS current
DESCRIPTION
"Represents a binding between an datapathEventHdlrTable
instance and a list of eventHdlrAuthProtocolTable
instances."
::= { eventHdlrAuthProtocolEntry 2}
eventHdlrAuthProtocolAuthMechanism OBJECT-TYPE
SYNTAX INTEGER {
PAP (0),
CHAP (1),
EAP_MD5(2),
EAP_TLS(3)
}
STATUS current
DESCRIPTION
"The authentication protocol that may be used for an
access request."
::= { 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 -- This PRC specifies the context information to send to the PDP
-- when an event is caught. The context information to send is -- when an event is caught. The context information to send is
-- described in terms of the PRC data types to include in the -- described in terms of the PRC data types to include in the
-- request, the level of encapsulated data and the interface -- request, the level of encapsulated data and the interface
-- information for that request. -- information for that request.
contextDataTable OBJECT-TYPE contextDataTable OBJECT-TYPE
skipping to change at page 69, line 44 skipping to change at line 3508
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
(the assigned OID) of the class which needs to be filled (the assigned OID) of the class which needs to be filled
in by the PEP and included with a PEP 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,
contextDataIfElement PrcIdentifier, contextDataIfElement PrcIdentifierOid,
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."
skipping to change at page 70, line 24 skipping to change at line 3537
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Defines the grouping of contextData instances "Defines the grouping of contextData instances
that are applicable to a given eventHdlrElement. When that are applicable to a given eventHdlrElement. When
instances of this PRC are sent to the PEP without the instances of this PRC are sent to the PEP without the
event Handler information, this attribute is unused." event Handler information, this attribute is unused."
::= { contextDataEntry 2} ::= { contextDataEntry 2}
contextDataIfElement OBJECT-TYPE contextDataIfElement OBJECT-TYPE
SYNTAX PrcIdentifier SYNTAX PrcIdentifierOid
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 request or event-specific ContextData Response." the PEP request or event-specific ContextData Response."
::= { contextDataEntry 3} ::= { contextDataEntry 3}
contextDataEncapsulation OBJECT-TYPE contextDataEncapsulation OBJECT-TYPE
SYNTAX INTEGER SYNTAX INTEGER
STATUS current STATUS current
skipping to change at page 76, line 4 skipping to change at line 3821
ContextData instance specified an ContextData instance specified an
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."
::= { ctxt802HdrEntry 7 } ::= { ctxt802HdrEntry 7 }
-- --
-- CtxtDialupInterface Table -- conformance section tbd
-- --
ctxtDialupInterfaceTable OBJECT-TYPE END
SYNTAX SEQUENCE OF CtxtDialupInterfaceEntry
PIB-ACCESS notify 10. Identity Extensions PIB
STATUS current
--
-- The AccessBind Identity Extensions PIB Module
--
ACCESSBIND-IDENTEXT-PIB PIB-DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, MODULE-COMPLIANCE,
OBJECT-TYPE, OBJECT-GROUP, pib
FROM COPS-PR-SPPI
InstanceId, Prid
FROM COPS-PR-SPPI-TC
TruthValue
FROM SNMPv2-TC;
accessBindIdentityExtPib MODULE-IDENTITY
SUBJECT-CATEGORIES { all }
LAST-UPDATED "200211032002Z"
ORGANIZATION "IETF RAP WG"
CONTACT-INFO "
Walter Weiss
Ellacoya Networks
7 Henry Clay Drive
Merrimack, NH 03054
Phone: 603-879-7364
E-mail: wweiss@ellacoya.com
"
DESCRIPTION DESCRIPTION
"Dialup Interface context data." "A PIB module containing the set of classes to
associate authentication protocols with configured
event handlers, and outsource authentication events
as they occur."
::= { contextClasses 4 } ::= { pib 7 } -- xxx to be assigned by IANA
ctxtDialupInterfaceEntry OBJECT-TYPE --
SYNTAX CtxtDialupInterfaceEntry -- The branch OIDs in the AccessBind Signalling PIB
--
identEventHdlrClasses OBJECT IDENTIFIER ::= {
accessBindIdentityExtPib 1 }
identAuthClasses OBJECT IDENTIFIER ::= {
accessBindIdentityExtPib 2 }
--
-- Identity 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.
identityEventHdlrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IdentityEventHdlrEntry
PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Entry oid of the ctxtDialupInterfaceTable PRC." "The identityEventHdlrTable 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
identityEventHdlrTable can be said to create eventTable
entries for user access. "
PIB-INDEX { ctxtDialupInterfaceId } ::= { identEventHdlrClasses 1 }
UNIQUENESS { }
::= { ctxtDialupInterfaceTable 1 } identityEventHdlrEntry OBJECT-TYPE
SYNTAX IdentityEventHdlrEntry
STATUS current
DESCRIPTION
"identityEventHdlrTable entry."
EXTENDS { eventHandlerEntry }
UNIQUENESS { eventHandlerElements,
eventHandlerNonMatchNext,
identityEventHdlrRequestAuth
}
CtxtDialupInterfaceEntry::= SEQUENCE { ::= { identityEventHdlrTable 1}
ctxtDialupInterfaceId InstanceId,
ctxtDialupInterfaceNASPort Integer32, IdentityEventHdlrEntry ::= SEQUENCE {
ctxtDialupInterfaceNASPortId OCTET STRING, identityEventHdlrRequestAuth TruthValue,
ctxtDialupInterfaceNASPortType INTEGER, identityEventHdlrAuthProtocol TagReferenceId
ctxtDialupInterfaceCalledStationId OCTET STRING,
ctxtDialupInterfaceCallingStationId OCTET STRING,
ctxtDialupInterfaceConnectInfo OCTET STRING
} }
ctxtDialupInterfaceId OBJECT-TYPE identityEventHdlrRequestAuth OBJECT-TYPE
SYNTAX InstanceId SYNTAX TruthValue
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An index to uniquely identify an instance of this "Boolean flag, if set to 'true' requires authentication
provisioning class." data to be sent in the request sent to the PDP with the
access event."
::= { ctxtDialupInterfaceEntry 1 } ::= { identityEventHdlrEntry 1}
ctxtDialupInterfaceNASPort OBJECT-TYPE identityEventHdlrAuthProtocol OBJECT-TYPE
SYNTAX Integer32 SYNTAX TagReferenceId
PIB-TAG { eventHdlrAuthProtocolGroup }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This Attribute indicates the physical port number of the "References a group of eventHdlrAuthProtocol instances,
NAS which is authenticating the user. It is only used in each of which specifies an authentication mechanism."
Access-Request packets. Note that 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."
::= { ctxtDialupInterfaceEntry 2 } ::= { identityEventHdlrEntry 2}
ctxtDialupInterfaceNASPortId OBJECT-TYPE --
SYNTAX OCTET STRING -- EventHdlrAuthProtocol Table
--
-- This PRC specifies the Auth Mechanism to use in the Access
-- request when a identity Event Handler is configured to
-- catch access events.
--
eventHdlrAuthProtocolTable OBJECT-TYPE
SYNTAX SEQUENCE OF EventHdlrAuthProtocolEntry
PIB-ACCESS install
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This Attribute contains a text string which identifies "This class lists the authentication protocols that can
the port of the NAS which is authenticating the user. It be used for an access request."
is only used in Access-Request and Accounting-Request
packets. Note that 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. "
::= { ctxtDialupInterfaceEntry 3 } ::= { identEventHdlrClasses 2 }
ctxtDialupInterfaceNASPortType OBJECT-TYPE eventHdlrAuthProtocolEntry OBJECT-TYPE
SYNTAX INTEGER { SYNTAX EventHdlrAuthProtocolEntry
radAsync(0),
radSync(1),
radIsdnSync(2),
radIsdnAsyncV120(3),
radIsdnAsyncV110(4),
radVirtual(5),
radPIAFS(6),
radHdlcClearChannel(7),
radX25(8),
radX75(9),
radG3Fax(10),
radSDSL(11),
radAdslCAP(12),
radAdslDMT(13),
radIdsl(14),
radEthernet(15),
radXdsl(16),
radCable(17),
radWirelessOther(18),
radWirelessIEEE80211(19)
}
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This Attribute indicates the type of the physical port "An instance of this class describes an authentication
of the NAS which is authenticating the user. It can be protocol that may be used for an access request.
used instead of or in addition to the radNasPort (5) Instances of this class that share the same TagId value
attribute. It is only used in Access-Request packets. collectively constitute a list of authentication
Either radNasPort (5) or radNasPortType or both SHOULD be protocols that may be used for a given access request"
present in an Access-Request packet, if the NAS PIB-INDEX { eventHdlrAuthProtocolId }
differentiates among its ports. UNIQUENESS { eventHdlrAuthProtocolGroup,
eventHdlrAuthProtocolAuthMechanism
}
A value of 'radAsync(0)' indicates Async. ::= { eventHdlrAuthProtocolTable 1}
A value of 'radSync(1)' indicates Sync. EventHdlrAuthProtocolEntry::= SEQUENCE {
eventHdlrAuthProtocolId InstanceId,
eventHdlrAuthProtocolGroup TagId,
eventHdlrAuthProtocolAuthMechanism INTEGER
}
A value of 'radIsdnSync(2)' indicates ISDN Sync. eventHdlrAuthProtocolId OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An arbitrary integer index that uniquely identifies an
instance of the ContextDataTable class."
A value of 'radIsdnAsyncV120(3)' indicates ISDN ::= { eventHdlrAuthProtocolEntry 1}
Async V.120.
A value of 'radIsdnAsyncV110(4)' indicates ISDN eventHdlrAuthProtocolGroup OBJECT-TYPE
Async V.110. SYNTAX TagId -- corresponding TagReference
-- in identityEventHdlrEntry
STATUS current
DESCRIPTION
"Represents a binding between an identityEventHdlrTable
instance and a list of eventHdlrAuthProtocolTable
instances."
A value of 'radVirtual(5)' indicates Virtual. ::= { eventHdlrAuthProtocolEntry 2}
Virtual refers to a connection to the NAS via some
transport protocol, instead of through a physical
port. For example, if a user telnetted into a NAS to
authenticate himself as an Outbound-User, the
Access-Request might include radNasPortType =
Virtual as a hint to the RADIUS server that the user
was not on a physical port.
A value of 'radPIAFS(6)' indicates PIAFS. PIAFS is a eventHdlrAuthProtocolAuthMechanism OBJECT-TYPE
form of wireless ISDN commonly used in Japan, and SYNTAX INTEGER {
stands for PHS (Personal Handyphone System) Internet PAP (0),
Access Forum Standard (PIAFS). CHAP_MD5 (1),
CHAP_MS (2),
EAP_MD5(3),
EAP_TLS(4)
}
STATUS current
DESCRIPTION
"The authentication protocol that may be used for an
access request. Based on this attribute the
corresponding Auth Extensions PRC must be used as
defined under the identAuthClasses branch. For
CHAP_MD5, and CHAP_MS, the same authChapExtTable must
be used."
::= { eventHdlrAuthProtocolEntry 3}
A value of 'radHdlcClearChannel(7)' indicates HDLC --
Clear Channel. -- Authentication Extension Tables
--
A value of 'radX25(8)' indicates X.25. --
-- AuthExtensions Base Table
--
A value of 'radX75(9)' indicates X.75. authExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF AuthExtEntry
PIB-ACCESS install-notify
STATUS current
DESCRIPTION
"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 uses the
information to authenticate the PEP's access request.
This PRC itself should not be instantiated.
A value of 'radG3Fax(10)' indicates G.3 Fax. This is a 'transient' class. Its instances are temporary
and are deleted by the PEP after a certain time/event.
Thus it must not be referred to by the server."
A value of 'radSDSL(11)' indicates SDSL " Symmetric ::= { identAuthClasses 1 }
DSL.
A value of 'radAdslCAP(12)' indicates ADSL-CAP - authExtEntry OBJECT-TYPE
Asymmetric DSL, Carrierless Amplitude Phase SYNTAX AuthExtEntry
Modulation. STATUS current
DESCRIPTION
"Entry oid for the AuthExtTable PRC."
A value of 'radAdslDMT(13)' indicates ADSL-DMT - PIB-INDEX { authExtId }
Asymmetric DSL, Discrete Multi-Tone. UNIQUENESS { }
A value of 'radIdsl(14)' indicates IDSL " ISDN ::= { authExtTable 1 }
Digital Subscriber Line.
A value of 'radEthernet(15)' indicates Ethernet. AuthExtEntry ::= SEQUENCE {
authExtId InstanceId
}
A value of 'radXdsl(16)' indicates xDSL - Digital authExtId OBJECT-TYPE
Subscriber Line of unknown type. SYNTAX InstanceId
STATUS current
DESCRIPTION
"An index to uniquely identify an instance of the
entended provisioning class."
A value of 'radCable(17)' indicates Cable. ::= { authExtEntry 1 }
A value of 'radWirelessOther(18)' indicates Wireless --
- Other. -- UserAuthExt Table
--
A value of 'radWirelessIEEE80211(19)' indicates userAuthExtTable OBJECT-TYPE
Wireless - IEEE 802.11." SYNTAX SEQUENCE OF UserAuthExtEntry
::= { ctxtDialupInterfaceEntry 4 } PIB-ACCESS notify
STATUS current
DESCRIPTION
"This is a concrete PRC used to contain user
authentication fields. This PRC extends the base PRC
authExtEntry."
::= { identAuthClasses 2 }
ctxtDialupInterfaceCalledStationId OBJECT-TYPE userAuthExtEntry OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX UserAuthExtEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This Attribute allows the NAS to send in the Access- "Entry for the UserAuthExtTable PRC. InstanceId's for
Request packet the phone number that the user called, this extended PRC are assigned by the base PRC AuthExt
using Dialed Number Identification (DNIS) or similar [SPPI]."
technology. Note that this may be different from the
phone number the call comes in on. It is only used in
Access-Request packets. "
::= { ctxtDialupInterfaceEntry 5 }
ctxtDialupInterfaceCallingStationId OBJECT-TYPE EXTENDS { authExtEntry }
UNIQUENESS { }
::= { userAuthExtTable 1 }
UserAuthExtEntry ::= SEQUENCE {
userAuthExtRealm OCTET STRING,
userAuthExtUsername OCTET STRING
}
userAuthExtRealm OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX OCTET STRING
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This Attribute allows the NAS to send in the Access- "user realm octet string."
Request packet the phone number that the user is calling
from, using Dialed Number Identification (DNIS) or
similar technology. Note that this may be different from
the phone number called. It is only used in
Access-Request packets. "
::= { ctxtDialupInterfaceEntry 6 }
ctxtDialupInterfaceConnectInfo OBJECT-TYPE ::= { userAuthExtEntry 1 }
userAuthExtUsername OBJECT-TYPE
SYNTAX OCTET STRING SYNTAX OCTET STRING
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"This Attribute allows the NAS to send in the Access- "Username octet string."
Request packet the phone number that the call came from,
using Automatic Number Identification (ANI) or similar
technology. It is only used in Access-Request packets."
::= { ctxtDialupInterfaceEntry 7 }
--- ::= { userAuthExtEntry 2 }
--- CtxtDialupInterfaceFramedProtocol Table
---
ctxtDialupIfFramedProtocolTable OBJECT-TYPE --
SYNTAX SEQUENCE OF CtxtDialupIfFramedProtocolEntry -- AuthChapExt Table
--
authChapExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF AuthChapExtEntry
PIB-ACCESS notify PIB-ACCESS notify
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"." "This is a concrete PRC used to contain CHAP
authentication fields. This PRC extends the PRC
::= { contextClasses 5 } userAuthExtEntry."
ctxtDialupIfFramedProtocolEntry OBJECT-TYPE ::= { identAuthClasses 3 }
SYNTAX CtxtDialupIfFramedProtocolEntry authChapExtEntry OBJECT-TYPE
SYNTAX AuthChapExtEntry
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Entry oid of the ctxtDialupIfFramedProtocolTable PRC." "Entry oid for the AuthChapExtTable PRC. InstanceId's for
this extended PRC are assigned by the base PRC [SPPI]."