PANA Working Group Y. El Mghazli
Internet-Draft Alcatel
Expires: August 13, 2004 Y. Ohba
Toshiba
J. Bournelle
GET/INT
February 13, 2004
SNMP usage for PAA-2-EP interface
<draft-yacine-pana-snmp-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The PANA Authentication Agent (PAA) does not necessarily act as an
Enforcement Point (EP) to prevent unauthorized access or usage of the
network. When a PANA Client (PaC) successfully authenticates itself
to the PAA, EP(s) (e.g., access routers) will need to be suitably
notified. The PANA working group mandates the use of Simple Network
Management Protocol (SNMP) to deliver the authorization information
to one or more EPs when the PAA is separated from EPs.
The present document provides the necessary information and
El Mghazli, et al. Expires August 13, 2004 [Page 1]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
extensions needed to use SNMP as the PAA-2-EP protocol.
Table of Contents
1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Internet-Standard Management Framework . . . . . . . . . 5
4. SNMP Applicability with the PANA framework . . . . . . . . . 6
4.1 SNMPv3 General applicability . . . . . . . . . . . . . . . . 6
4.2 Compliancy of SNMP against the PAA-EP requirements . . . . . 7
4.2.1 Authorization Consideration . . . . . . . . . . . . . . . . 7
4.2.2 One-to-many PAA-EP relation . . . . . . . . . . . . . . . . 8
4.2.3 Secure Communication . . . . . . . . . . . . . . . . . . . . 8
4.2.4 Notification of PaC presence . . . . . . . . . . . . . . . . 8
4.2.5 Accounting Consideration . . . . . . . . . . . . . . . . . . 9
4.2.6 Peer Liveness Test and Rebooted Peer Detection . . . . . . . 9
5. Applicability of IPSec configuration MIBs . . . . . . . . . 11
5.1 General Access Control . . . . . . . . . . . . . . . . . . . 11
5.2 IPSec Access Control . . . . . . . . . . . . . . . . . . . . 13
5.3 Notification of PaC presence . . . . . . . . . . . . . . . . 14
6. EP Configuration Example . . . . . . . . . . . . . . . . . . 16
6.1 General Access Control . . . . . . . . . . . . . . . . . . . 16
6.2 IPSec-based Access Control . . . . . . . . . . . . . . . . . 16
7. PANA extension to the IPSec SPD MIB . . . . . . . . . . . . 17
7.1 PANA MIB Overview . . . . . . . . . . . . . . . . . . . . . 17
7.2 PANA-specific objects definition . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
Normative References . . . . . . . . . . . . . . . . . . . . 28
Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . 32
El Mghazli, et al. Expires August 13, 2004 [Page 2]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
1. Glossary
PANA: Protocol for Carrying Authentication for Network Access.
PaC (PANA Client): The client side of the protocol that resides in
the host device, which is responsible for providing the
credentials to prove its identity for network access
authorization.
DI (Device Identifier): The identifier used by the network as a
handle to control and police the network access of a client.
Depending on the access technology, this identifier might contain
any of IP address, link- layer address, switch port number, etc.
of a connected device.
PAA (PANA Authentication Agent): The access network side entity of
the protocol whose responsibility is to verify the credentials
provided by a PANA client and grant network access service to the
device associated with the client and identified by a DI.
EP (Enforcement Point): A node on the access network where
per-packet enforcement policies (i.e., filters) are applied on the
inbound and outbound traffic of client devices. Information such
as DI and (optionally) cryptographic keys are provided by PAA per
client for constructing filters on the EP.
El Mghazli, et al. Expires August 13, 2004 [Page 3]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
2. Introduction
Client access authentication should be followed by access control to
make sure only authenticated and authorized clients can send and
receive IP packets via access network. Access control can involve
setting access control lists on the enforcement points.
Identification of clients, which are authorized to access the
network, is done by the PANA protocol exchange.
PANA does not assume that the PAA is always co-located with the
EP(s). Network access enforcement can be provided by one or more
nodes on the same IP subnet as the client (e.g., multiple routers).
When the PAA and the EP(s) are separated, there needs to be another
transport for client provisioning. This PAA-2-EP transport is needed
to create access control lists to allow authenticated and authorized
clients' traffic through the EPs.
The present document provides the necessary information and
extensions needed to use SNMP as the PAA-2-EP protocol.
2.1 scope
The next section 3 gives references for the SNMP framework.
Then section 4 provides a general statement with regards to the
applicability of SNMP as the PAA-2-EP protocol.
IPSec MIB modules were found to have general applicability and
varying levels of re-usability for PANA EP configuration using SNMP.
Section 5 details the applicability of this MIB set to the EP
configuration.
Section 6 provides usage examples of these MIB modules in the context
of PANA.
Section 7 defines some additional PANA-specific objects that extend
the IPSec-SPD-MIB module in order to entirely satisfy the PAA-2-EP
interface requirements.
Finally, section 8 addresses the security considerations.
El Mghazli, et al. Expires August 13, 2004 [Page 4]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
3. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
El Mghazli, et al. Expires August 13, 2004 [Page 5]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
4. SNMP Applicability with the PANA framework
This section provides a general statement with regards to the
applicability of SNMP as the PAA-2-EP protocol. This analysis of SNMP
is specific to SNMPv3, which provides the security required for PANA
usage. SNMPv1 and SNMPv2c would be inappropriate for PANA since they
have been declared Historic, and because their messages have only
trivial security.
4.1 SNMPv3 General applicability
The primary advantages of SNMPv3 are that it is a mature, well
understood protocol, currently deployed in various scenarios, with
mature toolsets available for SNMP managers and agents.
Application intelligence is captured in MIB modules, rather than in
the messaging protocol. MIB modules define a data model of the
information that can be collected and configured for a managed
functionality. The SNMP messaging protocol transports the data in a
standardized format without needing to understand the semantics of
the data being transferred. The endpoints of the communication
understand the semantics of the data.
Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly
due to variations in configuration requirements across vendors, few
MIB modules have been developed that enable standardized
configuration of managed devices across vendors. Since monitoring can
be done using only a least-common-denominator subset of information
across vendors, many MIB modules have been developed to provide
standardized monitoring of managed devices. As a result, SNMP has
been used primarily for monitoring rather than for configuring
network nodes.
SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c
versions. Specifically, SNMPv3 shares the separation of data modeling
(MIBs) from the protocol to transfer data, so all existing MIBs can
be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, and it
shares operations and transport with SNMPv2c. The major difference
between SNMPv3 and earlier versions is the addition of strong message
security and controlled access to data.
SNMPv3 uses the architecture detailed in [RFC3411], where all SNMP
entities are capable of performing certain functions, such as the
generation of requests, response to requests, the generation of
asynchronous notifications, the receipt of notifications, and the
proxy-forwarding of SNMP messages. SNMP is used to read and
manipulate virtual databases of managed-application-specific
operational parameters and statistics, which are defined in MIB
El Mghazli, et al. Expires August 13, 2004 [Page 6]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
modules.
4.2 Compliancy of SNMP against the PAA-EP requirements
[I-D.yacine-pana-paa2ep-prot-eval] gives further details about the
choice of SNMP as the PAA-2-EP protocol.
The following section illustrate how all the PAA-2-EP protocol
requirements are fully supported by SNMP:
4.2.1 Authorization Consideration
This section discusses PAA-EP communication in terms of authorization
aspects.
Filter Rule Installation: Filtering rules to be installed on EP
generally include a device- identifier of PaC, and also
cryptographic keying material (such as keys, key pairs, and
initialization values) when needed. The keying material is needed
when attackers can eavesdrop and spoof on the device identifiers
easily. Each keying material is uniquely identified with a keying
material name and has a lifetime for key management purpose. The
keying material is used with link-layer or network-layer ciphering
to provide additional protection. In addition to the device
identifier and keying material, other filter rules, such as the IP
filter rules specified in NAS-Filter-Rule AVPs carried in Diameter
EAP application [I-D.ietf-aaa-eap] may be installed on EP.
Using SNMP to configure the EPs, one can re-use existing MIBs,
this is detailed in section 5. Additional PANA-specific objects
may be needed and are defined in section 7.
Authorization Based on Maximum Amount of Units : In addition to
filter rules, there is another type of authorization parameter in
which the maximum amount of units is specified as an authorization
parameter. The type of units can be time (e.g., authorization
lifetime), volume (e.g., the number of incoming and/or outgoing
packets and/or bytes), service specific or money depending on the
type of service event [I-D.ietf-aaa-diameter-cc].
There are two possible methods to support this type of
authorization model: polling and notification. In the polling
model, the PAA (most probably) periodically sends its EP(s)
queries on the current amount of units used by each PaC. In the
notification model, the PAA sends the maximum amount units to
EP(s) when a PaC is successfully authenticated and authorized, and
waits notification events from EP(s). The notification events are
sent by EP(s) when each PaC has spent the maximum amount of units.
El Mghazli, et al. Expires August 13, 2004 [Page 7]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
With the use of SNMPv3 as the PAA- EP protocol, the polling and
notification models are supported by SNMP get and trap operations,
respectively. In general, the polling model is less scalable than
the notification model as the number of PaCs and/or EPs increases.
On the other hand, the notification model based on SNMP trap is
unreliable since SNMP Trap message is not responded. However, SNMP
applications can be designed to add reliability to the trap
operation, by sending SNMP query to the sender of the Trap message
from PAA when a Trap message is received. Thus, the notification
model should be used for supporting this type of authorization.
This type of authorization might also require that the
communicating pair of PAA and EP to detect a dead or rebooted peer
in order to avoid possible inaccurate accounting. This aspect is
discussed in section 4.2.6.
4.2.2 One-to-many PAA-EP relation
This means that there might be multiple EPs per PAA. The SNMP
framework [RFC3410] clearly states that an SNMP manager (PAA) can
communicate simultaneously with several agents (EPs).
4.2.3 Secure Communication
SNMPv3 includes the User-based Security Model [RFC3414], which
defines three standardized methods for providing authentication,
confidentiality, and integrity. Additionally, USM has specific
built-in mechanisms for preventing replay attacks including unique
protocol engine IDs, timers and counters per engine and time windows
for the validity of messages.
See section 8.
4.2.4 Notification of PaC presence
PaC may also choose to start sending packets before getting
authenticated. In that case, the network should detect this and the
PAA must send an unsolicited PANA-Start-Request message to PaC. EP is
the node that can detect such activity. In case they are separate,
there needs to be an explicit message to prompt PAA.
The PAA-2-EP protocol may allow the EP to notify a new PaC to the
PAA. When SNMPv3 is used as the PAA-EP protocol, such a presence
notification is done by using the SNMP trap operation. See section
5.3 for details on how new and existing SNMP objects provide this
feature.
El Mghazli, et al. Expires August 13, 2004 [Page 8]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
4.2.5 Accounting Consideration
Since authentication and authorization are closely related to
accounting in many cases, accounting aspects need to be considered in
the PAA-EP protocol. There are logically two models with regard to
where the accounting client is located.
In the first model, the accounting client is co-located with PAA. The
PAA device acts as an accounting client of a AAA protocol. The PAA
collects accounting information from the EP(s) it controls, and sends
the gathered data to the accounting server by using the AAA protocol.
In the case where accounting is performed in usage basis, i.e., the
number of transmitted/received octets/packets, the PAA-EP protocol
also needs to carry these usage data.
In the second model, the accounting client is co-located with EP. In
this model, the EP device acts as an accounting client of a AAA
protocol. The EP obtains the authentication/authorization session
identifier for each PaC from the PAA, where the authentication/
authorization session identifier is assigned by a AAA protocol
running on the PAA, and sends the accounting information directly to
the accounting server by using the AAA protocol, without sending the
accounting information to the PAA.
The authentication/authorization session identifier of a AAA protocol
is used by the accounting server to associate accounting information
with a particular authentication/authorization session to calculate
bills. The authentication/authorization session identifier may or
may not be the same as the PANA session identifier.
Both models might need for the communicating pair of PAA and EP to
detect a dead or rebooted peer to avoid possible inaccurate
accounting. This aspect is discussed in section 4.2.6.
4.2.6 Peer Liveness Test and Rebooted Peer Detection
PAA-EP protocol implementations need to be stateful when considering
the authorization and accounting aspects as described in the previous
sections. The stateful nature provides the functionality to detect a
dead or rebooted peer in a timely fashion. On the other hand, this
does not mean that the PAA-EP protocol itself needs to be stateful.
For example, an SNMP entity (i.e., an SNMP engine plus SNMP
applications) can generate SNMP queries on a particular MIB at an
interval shorter enough to perform peer liveness test and rebooted
peer detection.
Also, the peer liveness test and rebooted peer detection need to be
performed securely.
El Mghazli, et al. Expires August 13, 2004 [Page 9]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
When SNMPv3 is used as the PAA-EP protocol, the SNMP management
framework supports snmpEngineBoots MIB [RFC3411]. By periodically
sending SNMP query to the peer to check the current value of this MIB
with the use of SNMP Security Subsystem, it is possible for an SNMP
entity to securely perform peer liveness test and rebooted peer
detection between PAA and EP.
When a PAA finds a dead or rebooted EP, the PAA should immediately
terminate PANA sessions for PaCs that are authorized for access
through the EP.
El Mghazli, et al. Expires August 13, 2004 [Page 10]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
5. Applicability of IPSec configuration MIBs
This section details the applicability of existing IPSec
configuration MIB modules to the EP configuration. These were found
to have general applicability and a fair level of re-usability for
PANA EP configuration:
IPSec Security Policy Database (SPD) MIB
[I-D.ietf-ipsp-ipsec-conf-mib]:
This document defines a MIB module for configuration of an IPsec SPD.
No IPsec or IKE specific actions are defined within this document.
IPSec IKE Action MIB [I-D.ietf-ipsp-ikeaction-mib]:
This document defines a MIB module for configuration of an IKE action
within the IPsec security policy database (SPD).
The IPSec Configuration MIBs set does not define MIB modules for
monitoring the state of an IPsec device. Neither it does define MIB
modules for configuring other policy related actions. The purpose of
these MIBs is to allow administrators to be able to configure policy
with respect to the IPsec [RFC2401]/IKE [RFC2409] protocols.
5.1 General Access Control
The PAA must provision its EPs with DI-based filters in order to
control and police the network access of a PaC. According to the
definition of the Device Identifier in [I-D.ietf-pana-requirements],
such filters - depending on the access technology - might contain any
of IP address or link-layer address of a connected device. See
section 4.2.1 for further considerations.
Do note also that keying material might be provisioned for the
particular case where access control is performed using IPSec
[I-D.ietf-pana-ipsec]. This particular case is detailed in next
section 5.2.
The IPSec SPD MIB module is designed to configure an IPsec security
policy database in a policy and rule oriented fashion. This module
is divided into 3 portions (Rules, Filters, Actions). Specifically,
the SPD MIB provides a generic mechanism for performing packet
processing based on a rule set.
The policy-based packet filtering and the corresponding execution of
actions is of a more general nature than for IPsec configuration
only, such as for configuration of a firewall. Rules within the IPSec
Configuration MIB are generic and simply bind a filter to an action.
El Mghazli, et al. Expires August 13, 2004 [Page 11]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
Filters provided within the IPSec MIB itself are numerous and fairly
complete for most common packet filtering usage but externally
defined filters are supported.
-- Ipv4/v6 address-based filter
For Ipv4/v6 address-based filters provisioning, the IPSec SPD MIB
module (SPD-MIB) provides means to filter the traffic based on the
IP header information. SPD-MIB "spdIpHeaderFilter" table provides
such facilities: one can define the various tests that are used
when evaluating a given IP packet. The various tests definable in
this table are as follows:
Source Address Match
Destination Address Match
Source Port Range Match
Destination Port Range Match
Protocol Match
IPv6 Flow Label Match (Ipv6 only)
The results of each test are ANDed together to produce the result
of the entire filter.
-- L2 address-based filter
For Layer 2 address-based classification, additional filters might
be designed if needed. Section 7 defines a IEEE 802-based filter,
which may be useful in appropriate access networks. The various
tests definable in this table are as follows:
Source Address (802) Match
Destination Address (802) Match
VlanId Match
VlanTag Test
IEEE 802 EtherType Match
El Mghazli, et al. Expires August 13, 2004 [Page 12]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
802.1 UserPriority Match
-- Static Actions
The actions encapsulated within this module are basic drop/accept
actions. These are sufficient to perform EP general access control
at the EP.
5.2 IPSec Access Control
The PANA protocol authenticates the client and also establishes a
PANA security association between the PANA client and PANA
authentication agent at the end of successful authentication. The
PANA authentication agent (PAA) indicates the results of the
authentication using the PANA-Bind-Request message wherein it can
indicate the access control method enforced by the access network and
the IP address of the corresponding EP.
When IPSec is used to perform access control, the PANA protocol
[I-D.ietf-pana-pana] does not discuss any details of IPsec [RFC2401]
SA establishment. Indeed, [I-D.ietf-pana-ipsec] discusses the details
for establishing an IPsec security association between the PaC and
the EP. When the IPsec SA is successfully established, it can be used
to enforce access control and specifically used to prevent the
service theft mentioned in [I-D.ietf-pana-threats-eval].
In this particular context, one assumes that the following have
already happened before the IPSec SA is established:
PANA client (PaC) and PAA mutually authenticate each other using
EAP methods that derive Master Session Key (MSK).
PaC learns the IP address of the Enforcement point (EP) during the
PANA exchange.
PaC learns that the network uses IPsec [RFC2401] for securing the
link between PaC and EP during the PANA exchange.
PaC configures an IP address address before the PANA protocol
begins.
The IPSec IKE Action MIB module (IKEACTION-MIB) works within the
framework of the IPsec Security Policy Database Configuration MIB
(SPD-MIB). It can be referenced as an action by the SPD-MIB and is
used to configure IKE negotiations between network devices. Hence,
together with the SPD-MIB, the IKEACTION-MIB module enables the PAA
to configure IPSEC-based access control at the EP.
El Mghazli, et al. Expires August 13, 2004 [Page 13]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
The PAA is then responsible to communicate to EP the following before
IKE phase 1 exchange begins:
the IKE pre-shared key:
To this end, the PAA must set a row in the IKE Credential Filter
table of the IKEACTION-MIB. This table defines filters, which can
be used to match credentials of IKE peers, where the credentials
in question have been obtained from an IKE phase 1 exchange. They
may be X.509 certificates, Kerberos tickets, or Pre-shared keys,
etc.
the IP address of the PaC
An IP Header Filter of the SPD-MIB is used for configuring the SPD
accordingly. See the previous section 5.1 for further details.
the PANA session ID (optionally)
[I-D.ietf-pana-ipsec] states that aggressive mode must be
supported. Pac and EP should use the PANA session ID (see
[I-D.ietf-pana-pana]) as the payload of the ID_KEY_ID in
aggressive mode for establishing the phase 1 SA. To this end, the
PAA must use the IKE Peer Identity Filter table of the
IKEACTION-MIB.
5.3 Notification of PaC presence
The SPD-MIB provides a means to notify to the SNMP manager (PAA)
information on packets matching/not matching the filters of given
rule. Such notification mechanisms and objects can be re-used for
notifying the PAA that unauthorized packets are trying to pass
through the EP.
Section 7 defines a new SNMP notification, which aims at satisfying
this requirement. It re-uses existing notification variable objects
pre-defined in the SPD MIB.
This "New PaC" notification (panaNewPacNotification) is triggered
when the the EP detects traffic coming from an unauthorized source.
The objects sent must include ipspIPSourceType, ipspIPSourceAddress,
ipspIPDestinationType, and ipspIPDestinationAddress objects to
indicate the packet source and destination of the packet that
triggered the action. Additionally, the ipspIPInterfaceType,
ipspIPInterfaceAddress, and ipspPacketDirection objects are included
to indicate which interface the action was executed in association
with and if the packet was inbound or outbound through the endpoint.
El Mghazli, et al. Expires August 13, 2004 [Page 14]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
See [I-D.ietf-ipsp-ipsec-conf-mib] for further details.
El Mghazli, et al. Expires August 13, 2004 [Page 15]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
6. EP Configuration Example
6.1 General Access Control
TBD.
6.2 IPSec-based Access Control
TBD.
El Mghazli, et al. Expires August 13, 2004 [Page 16]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
7. PANA extension to the IPSec SPD MIB
Many existing IPSec MIB objects defined in the IPSec Configuration
MIB modules can be efficiently re-used for the PANA-specific needs.
This is detailed in section 5.
The following sections define additional PANA-specific objects that
extend the IPSec MIB module in order to entirely satisfy the PAA-2-EP
interface requirements.
7.1 PANA MIB Overview
. 802 filters
. "New PaC" notification
7.2 PANA-specific objects definition
PANA-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32
FROM SNMPv2-SMI
RowStatus, PhysAddress, StorageType, TimeStamp
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
spdMIB, spdActionExecuted, spdIPInterfaceType, spdIPInterfaceAddress,
spdIPSourceType, spdIPSourceAddress, spdIPDestinationType,
spdIPDestinationAddress, spdPacketDirection
FROM IPSEC-SPD-MIB;
-- Module identity
--
panaMIB MODULE-IDENTITY
LAST-UPDATED
"200402050000Z" -- 05 February 2004
El Mghazli, et al. Expires August 13, 2004 [Page 17]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
ORGANIZATION
"IETF PANA Working Group"
CONTACT-INFO
"Yacine El Mghazli
Alcatel
91460 Marcoussis, France
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr"
DESCRIPTION
"The MIB module for defining additional PANA-specific objects to
the IPSec SPD MIB. Copyright (C) The Internet Society (2003).
This version of this MIB module is part of RFC XXXX, see the
RFC itself for full legal notices."
-- Revision History
REVISION
"200402050000Z" -- 05 February 2004
DESCRIPTION
"Version 01, draft-yacine-pana-paa2ep-snmp-01.txt"
REVISION
"200310310000Z" -- 31 October 2003
DESCRIPTION
"Initial version, draft-yacine-pana-paa2ep-snmp-00.txt"
::= { spdMIB XXX } -- XXX to be assigned by IANA
--
-- groups of related objects
--
panaConfigObjects OBJECT IDENTIFIER
::= { panaMIB 1 }
panaNotificationObjects OBJECT IDENTIFIER
::= { panaMIB 2}
panaConformanceObjects OBJECT IDENTIFIER
::= { panaMIB 3 }
--
-- Textual Conventions
--
-- TBD.
--
-- PANA Additional Filters Objects
--
--
El Mghazli, et al. Expires August 13, 2004 [Page 18]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
-- The IEEE 802 Filter Table
--
pana802FilterTable OBJECT-TYPE
SYNTAX SEQUENCE OF Pana802FilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" IEEE 802-based filter definitions. A class that contains
attributes of IEEE 802 (e.g., 802.3) traffic that form
filters that are used to perform traffic classification."
::= { panaConfigObjects 1 }
pana802FilterEntry OBJECT-TYPE
SYNTAX Pana802FilterEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" IEEE 802-based filter definitions. An entry specifies
(potentially) several distinct matching components. Each
component is tested against the data in a frame
individually. An overall match occurs when all of the
individual components match the data they are compared
against in the frame being processed. A failure of any
one test causes the overall match to fail.
Wildcards may be specified for those fields that are not
relevant."
INDEX { pana802FilterName }
::= { pana802FilterTable 1 }
Pana802FilterEntry ::= SEQUENCE {
pana802FilterName SnmpAdminString,
pana802FilterType BITS,
pana802FilterDstAddr PhysAddress,
pana802FilterSrcAddr PhysAddress,
pana802FilterVlanId Integer32,
pana802FilterVlanTagRequired INTEGER,
pana802FilterEtherType Integer32,
pana802FilterUserPriority BITS,
pana802FiltLastChanged TimeStamp,
pana802FiltStorageType StorageType,
pana802FiltRowStatus RowStatus
}
pana802FilterName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
El Mghazli, et al. Expires August 13, 2004 [Page 19]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The administrative name for this filter. "
::= { pana802FilterEntry 1 }
pana802FilterType OBJECT-TYPE
SYNTAX BITS { srcAddress(0),
dstAddress(1),
vlanId(4),
etherType(5),
userPriority(6) }
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This defines the various tests that are used when evaluating
a given filter. The results of each test are ANDed together
to produce the result of the entire filter. When processing
this filter, it is recommended for efficiency reasons that
the filter halt processing the instant any of the specified
tests fail.
Once a row is 'active', this object's value may not be
changed unless all the appropriate columns needed by the new
value to be imposed on this object have been appropriately
configured. . "
::= { pana802FilterEntry 2 }
pana802FilterDstAddr OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 802 address against which the 802 DA of incoming
traffic streams will be compared. Frames whose 802 DA
matches the physical address specified by this object,
taking into account address wildcarding as specified by the
pana802FilterDstAddrMask object, are potentially subject to
the processing guidelines that are associated with this
entry through the related action class."
::= { pana802FilterEntry 3 }
pana802FilterSrcAddr OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The 802 MAC address against which the 802 MAC SA of
incoming traffic streams will be compared. Frames whose 802
El Mghazli, et al. Expires August 13, 2004 [Page 20]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
MAC SA matches the physical address specified by this
object, taking into account address wildcarding as specified
by the pana802FilterSrcAddrMask object, are potentially
subject to the processing guidelines that are associated
with this entry through the related action class."
::= { pana802FilterEntry 4 }
pana802FilterVlanId OBJECT-TYPE
SYNTAX Integer32 (-1 | 1..4094)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The VLAN ID (VID) that uniquely identifies a VLAN
within the device. This VLAN may be known or unknown
(i.e., traffic associated with this VID has not yet
been seen by the device) at the time this entry
is instantiated.
Setting the pana802FilterVlanId object to -1 indicates that
VLAN data should not be considered during traffic
classification."
::= { pana802FilterEntry 5 }
pana802FilterVlanTagRequired OBJECT-TYPE
SYNTAX INTEGER {
taggedOnly(1),
priorityTaggedPlus(2),
untaggedOnly(3),
ignoreTag(4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates whether the presence of an
IEEE 802.1Q VLAN tag in data link layer frames must
be considered when determining if a given frame
matches this 802 filter entry.
A value of 'taggedOnly(1)' means that only frames
containing a VLAN tag with a non-Null VID (i.e., a
VID in the range 1..4094) will be considered a match.
A value of 'priorityTaggedPlus(2)' means that only
frames containing a VLAN tag, regardless of the value
of the VID, will be considered a match.
A value of 'untaggedOnly(3)' indicates that only
untagged frames will match this filter component.
The presence of a VLAN tag is not taken into
consideration in terms of a match if the value is
'ignoreTag(4)'."
::= { pana802FilterEntry 6 }
El Mghazli, et al. Expires August 13, 2004 [Page 21]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
pana802FilterEtherType OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..'ffff'h)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies the value that will be compared
against the value contained in the EtherType field of an
IEEE 802 frame. Example settings would include 'IP'
(0x0800), 'ARP' (0x0806) and 'IPX' (0x8137).
Setting the pana802FilterEtherTypeMin object to -1 indicates
that EtherType data should not be considered during traffic
classification.
Note that the position of the EtherType field depends on
the underlying frame format. For Ethernet-II encapsulation,
the EtherType field follows the 802 MAC source address. For
802.2 LLC/SNAP encapsulation, the EtherType value follows
the Organization Code field in the 802.2 SNAP header. The
value that is tested with regard to this filter component
therefore depends on the data link layer frame format being
used. If this 802 filter component is active when there is
no EtherType field in a frame (e.g., 802.2 LLC), a match is
implied."
::= { pana802FilterEntry 7 }
pana802FilterUserPriority OBJECT-TYPE
SYNTAX BITS {
matchPriority0(0),
matchPriority1(1),
matchPriority2(2),
matchPriority3(3),
matchPriority4(4),
matchPriority5(5),
matchPriority6(6),
matchPriority7(7)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The set of values, representing the potential range
of user priority values, against which the value contained
in the user priority field of a tagged 802.1 frame is
compared. A test for equality is performed when determining
if a match exists between the data in a data link layer
frame and the value of this 802 filter component. Multiple
values may be set at one time such that potentially several
different user priority values may match this 802 filter
component.
Setting all of the bits that are associated with this
El Mghazli, et al. Expires August 13, 2004 [Page 22]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
object causes all user priority values to match this
attribute. This essentially makes any comparisons
with regard to user priority values unnecessary. Untagged
frames are treated as an implicit match."
::= { pana802FilterEntry 8 }
pana802FiltLastChanged OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when this row was last modified or
created either through SNMP SETs or by some other external
means."
::= { pana802FilterEntry 9 }
pana802FiltStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this row. Rows in this table which were
created through an external process may have a storage type
of readOnly or permanent."
DEFVAL { nonVolatile }
::= { pana802FilterEntry 10 }
pana802FiltRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates the conceptual status of this row.
This object may not be set to active if the requirements of
the pana802FilterType object are not met. In other words,
if the associated value columns needed by a particular test
have not been set, then attempting to change this row to an
active state will result in an inconsistentValue error. See
the pana802FilterType object description for further
details."
::= { pana802FilterEntry 11 }
--
--
-- Notification objects information
--
El Mghazli, et al. Expires August 13, 2004 [Page 23]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
--
panaNotifications OBJECT IDENTIFIER ::=
{ panaNotificationObjects 0 }
panaNewPacNotification NOTIFICATION-TYPE
OBJECTS { spdActionExecuted, spdIPInterfaceType,
spdIPInterfaceAddress,
spdIPSourceType, spdIPSourceAddress,
spdIPDestinationType,
spdIPDestinationAddress,
spdPacketDirection }
STATUS current
DESCRIPTION
"Notification that AP detected traffic coming from an
unauthorized source. The objects sent must include the
ipspActionExecuted which will indicate which action was executed
within the scope of the rule. Additionally, the ipspIPSourceType,
ipspIPSourceAddress, ipspIPDestinationType, and
ipspIPDestinationAddress, objects must be included to indicate the
packet source and destination of the packet that triggered the
action. The ipspIPInterfaceType, ipspIPInterfaceAddress, and
ipspPacketDirection objects are included to indicate which endpoint
the packet was associated with."
::= { panaNotifications 1 }
--
--
-- Conformance information
--
--
-- TBD.
END
El Mghazli, et al. Expires August 13, 2004 [Page 24]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
8. Security Considerations
-- if you have any read-write and/or read-create objects, please --
describe their specific sensitivity or vulnerability. -- RFC 2669 has
a very good example.
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
< list the tables and objects and state why they are sensitive >
-- else if there are no read-write objects in your MIB module
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB
module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
-- for all MIB modules you must evaluate whether any readable objects
-- are sensitive or vulnerable (for instance, if they might reveal --
customer information or violate personal privacy laws such as --
those of the European Union if exposed to unathorized parties)
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
<list the tables and objects and state why they are sensitive>
SNMP versions prior to SNMPv3 did not include adequate security. Even
if the network itself is secure (for example by using IPSec), even
then, there is no control as to who on the secure network is allowed
to access and GET/SET (read/change/create/delete) the objects in this
MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
El Mghazli, et al. Expires August 13, 2004 [Page 25]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
El Mghazli, et al. Expires August 13, 2004 [Page 26]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
9. Acknowledgements
This document leverages on similar works done in the MIDCOM working
group. Thanks to the authors of those IDs.
The author would like to thank Thomas Moore for his grateful help
during the edition of this document.
El Mghazli, et al. Expires August 13, 2004 [Page 27]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
Normative References
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-03 (work in
progress), February 2004.
[I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-07 (work in progress), June
2003.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA enabling IPsec based Access
Control", draft-ietf-pana-ipsec-01 (work in progress),
January 2004.
[I-D.ietf-pana-threats-eval]
Parthasarathy, M., "PANA Threat Analysis and security
requirements", draft-ietf-pana-threats-eval-04 (work in
progress), May 2003.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[I-D.ietf-ipsp-ipsec-conf-mib]
Baer, M., "IPsec Policy Configuration MIB",
draft-ietf-ipsp-ipsec-conf-mib-03 (work in progress), June
2002.
[I-D.ietf-ipsp-ikeaction-mib]
Hardaker, W., "IPsec Security Policy IKE Action MIB",
draft-ietf-ipsp-ikeaction-mib-00 (work in progress),
January 2004.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
El Mghazli, et al. Expires August 13, 2004 [Page 28]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC
2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
McCloghrie, K., Rose, M. and S. Waldbusser, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
El Mghazli, et al. Expires August 13, 2004 [Page 29]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
Informative References
[I-D.yacine-pana-paa2ep-prot-eval]
Mghazli, Y., "PANA PAA-EP protocol considerations",
draft-yacine-pana-paa2ep-prot-eval-00 (work in progress),
October 2003.
[I-D.yacine-pana-paa-ep-reqs]
Mghazli, Y., "PANA PAA-EP Protocol Requirements",
draft-yacine-pana-paa-ep-reqs-00 (work in progress),
October 2003.
[I-D.ietf-aaa-diameter-cc]
Hakala, H., "Diameter Credit-control Application",
draft-ietf-aaa-diameter-cc-02 (work in progress), December
2003.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-03 (work in progress), October 2003.
Authors' Addresses
Yacine El Mghazli (Editor)
Alcatel
Route de Nozay
Marcoussis 91460
France
EMail: yacine.el_mghazli@alcatel.fr
Yoshihiro Ohba
Toshiba America Information Systems, Inc.
9740 Irvine Blvd.
Irvine, CA 92619-1697
USA
EMail: yohba@tari.toshiba.com
El Mghazli, et al. Expires August 13, 2004 [Page 30]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
EMail: julien.bournelle@int-evry.fr
El Mghazli, et al. Expires August 13, 2004 [Page 31]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
El Mghazli, et al. Expires August 13, 2004 [Page 32]
Internet-Draft SNMP usage for PAA-2-EP interface February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
El Mghazli, et al. Expires August 13, 2004 [Page 33]