PANA Working Group Y. El Mghazli
Internet-Draft Alcatel
Expires: January 17, 2005 Y. Ohba
Toshiba
J. Bournelle
GET/INT
July 19, 2004
SNMP usage for PAA-EP interface
draft-ietf-pana-snmp-01
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 January 17, 2005.
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 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.
El Mghazli, et al. Expires January 17, 2005 [Page 1]
Internet-Draft SNMP usage for PAA-EP interface July 2004
The present document provides the necessary information and
extensions needed to use SNMP as the PAA-EP protocol.
Table of Contents
1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 PAA/EP separation context . . . . . . . . . . . . . . . . 4
2.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Internet-Standard Management Framework . . . . . . . . . . 6
4. SNMP Applicability with the PANA framework . . . . . . . . . . 7
4.1 SNMPv3 General applicability . . . . . . . . . . . . . . . 7
4.2 Compliancy of SNMP against the PANA requirements . . . . . 8
4.2.1 Authorization Consideration . . . . . . . . . . . . . 8
4.2.2 One-to-many PAA-EP relation . . . . . . . . . . . . . 9
4.2.3 Secure Communication . . . . . . . . . . . . . . . . . 9
4.2.4 Notification of PaC presence . . . . . . . . . . . . . 10
4.2.5 Accounting Consideration . . . . . . . . . . . . . . . 10
4.2.6 Peer Liveness Test and Rebooted Peer Detection . . . . 11
5. Applicability of IPSec configuration MIBs . . . . . . . . . . 12
5.1 General Access Control . . . . . . . . . . . . . . . . . . 12
5.2 IPSec Access Control . . . . . . . . . . . . . . . . . . . 13
5.3 Notification of PaC presence . . . . . . . . . . . . . . . 15
6. EP Configuration Example . . . . . . . . . . . . . . . . . . . 16
6.1 General IP-based Access Control . . . . . . . . . . . . . 16
6.2 IPSec-based Access Control . . . . . . . . . . . . . . . . 17
7. PANA extension to the IPSec SPD MIB . . . . . . . . . . . . . 20
7.1 PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 20
7.2 PANA-specific objects definition . . . . . . . . . . . . . 20
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1 MIB Usage Example . . . . . . . . . . . . . . . . . . . . 28
8.2 L2 Filtering Support . . . . . . . . . . . . . . . . . . . 28
8.3 L2 Protection Support . . . . . . . . . . . . . . . . . . 28
8.4 Security Section . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 32
11.2 Informative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 35
El Mghazli, et al. Expires January 17, 2005 [Page 2]
Internet-Draft SNMP usage for PAA-EP interface July 2004
1. Terminology and Definitions
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. A PaC is responsible
for requesting network access and engaging in authentication
process using the PANA protocol.
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 (server) side entity of the PANA protocol. A
PAA is in charge of interfacing with the PaCs for authenticating
and authorizing them for the network access service. To this end,
the PAA verifies the credentials provided by a PANA client and
grants network access service to the device associated with the
client and identified by a DI.
The PAA is also responsible for updating the access control state
(i.e., filters) depending on the creation and deletion of the
authorization state. The PAA communicates the updated state to
the enforcement points in the network. When the PAA and the EP
are separated, a protocol is required to carry the authorized
client attributes from the PAA to the EP. SNMP is mandated for
this task.
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. The EP uses non-cryptographic or cryptographic
filters to selectively allow and discard data packets. These
filters may be applied at the link-layer or the IP-layer. An EP
learns the attributes of the authorized clients (DI and
(optionally) cryptographic keys from the PAA.
El Mghazli, et al. Expires January 17, 2005 [Page 3]
Internet-Draft SNMP usage for PAA-EP interface July 2004
2. Introduction
2.1 PAA/EP separation context
PANA enables access control by identifying legitimate clients and
generating filtering information for access control mechanisms.
[I-D.ietf-pana-framework] defines a general AAA and access control
framework. The PANA protocol itself provides client authentication
and authorization functionality for securing network access. The
other component of a complete solution is the access control which
ensures that only authenticated and authorized clients can gain
access to the network.
Access control can be achieved by placing EPs (Enforcement Points) in
the network for policing the traffic flow. EPs should prevent data
traffic from and to any unauthorized client unless it's either PANA
or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
discovery, DHCP, etc.).
Figure 1 below illustrates the functional entities and the interfaces
(protocols, APIs) among them.
RADIUS/
Diameter/
+-----+ PANA +-----+ LDAP/ API +-----+
| PaC |<----------------->| PAA |<---------------->| AS |
+-----+ +-----+ +-----+
^ ^
| |
| +-----+ |
IKE/ +-------->| EP |<--------+ SNMP/ API
4-way handshake +-----+
Figure 1: PANA Functional Model
Some of the entities may be co-located depending on the deployment
scenario.
The EP on the access network allows general data traffic from any
authorized PaC, whereas it allows only limited type of traffic (e.g.,
PANA, DHCP, router discovery) for the unauthorized PaCs. This
ensures that the newly attached clients have the minimum access
service to engage in PANA and get authorized for the unlimited
service.
If the PaC is authorized to gain the access to the network, the PAA
also sends the PaC-specific attributes (e.g., IP address,
cryptographic keys, etc.) to the EP by using SNMP. The EP uses this
El Mghazli, et al. Expires January 17, 2005 [Page 4]
Internet-Draft SNMP usage for PAA-EP interface July 2004
information to enforce policy rules allowing data traffic from and to
the PaC to pass through.
In case a cryptographic access control needs to be enabled after the
PANA authentication, a secure association protocol runs between the
PaC and the EP. The PaC should already have the input parameters to
this process as a result of the successful PANA exchange. Similarly,
the EP should have obtained them from the PAA via SNMP. Secure
association exchange produces the required security associations
between the PaC and the EP to enable per-packet protection.
Finally data traffic can start flowing from and to the newly
authorized PaC.
2.2 Scope
Section 3 gives references for the SNMP framework.
Section 4 provides a general statement with regards to the
applicability of SNMP as the PAA-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 [I-D.ietf-ipsp-spd-mib] in order to entirely
satisfy the PAA-EP interface requirements.
Finally, Section 9 addresses the security considerations.
El Mghazli, et al. Expires January 17, 2005 [Page 5]
Internet-Draft SNMP usage for PAA-EP interface July 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
[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,
[RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580].
El Mghazli, et al. Expires January 17, 2005 [Page 6]
Internet-Draft SNMP usage for PAA-EP interface July 2004
4. SNMP Applicability with the PANA framework
This section provides a general statement with regards to the
applicability of SNMP as the PAA-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 January 17, 2005 [Page 7]
Internet-Draft SNMP usage for PAA-EP interface July 2004
modules.
4.2 Compliancy of SNMP against the PANA requirements
The following sections detail how the PAA-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 a cryptographic keying material (e.g.,
IKE pre-shared key [RFC2409]) when cryptographic data traffic
protection is needed. Each keying material is uniquely identified
with a keying material name (e.g., ID_KEY_ID in IKE [RFC2409]) and
has a lifetime for key management, accounting, access control and
security reasons in general. 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.
SNMP enables the re-use of existing MIBs, this is detailed in
Section 4. 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:
* In the polling model, the PAA (most probably) periodically
sends queries to its EP(s) 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 a PaC has spent the
El Mghazli, et al. Expires January 17, 2005 [Page 8]
Internet-Draft SNMP usage for PAA-EP interface July 2004
maximum amount of units. 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
A single PAA may control multiple EPs. The PAA may be separated from
any EP or co-located with a particular EP. This deployment might be
useful where it is preferable to run a AAA protocol at a single,
manageable point. This model is particularly useful in an access
network that consists of a large number of access points on which
per-packet access enforcement is made. When a PaC is authenticated
to the PAA, the PAA should install access control filters to each of
the EPs under control of the PAA if the PAA cannot tell which EP the
PaC is attached to. Even if the PAA can tell which EP the PaC is
attached to, the PAA may install access control filters to those EPs
if the PaC is a mobile device that can roam among the EPs. Such
pre-installation of filters can reduce handoff latency. If different
access authorization policies are applied to different EPs, different
filter rules for a PaC may be installed on different EPs.
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 (USM, [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 9.
El Mghazli, et al. Expires January 17, 2005 [Page 9]
Internet-Draft SNMP usage for PAA-EP interface July 2004
4.2.4 Notification of PaC presence
The 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 the PaC.
The EP is the node that can detect such activity. In case they are
separate, there needs to be an explicit message to prompt the PAA.
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.
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.
o 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.
o In the second model, the accounting client is co-located with the
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 the PAA and the
EP to detect a dead or rebooted peer to avoid possible inaccurate
accounting. This aspect is discussed in Section 4.2.6.
El Mghazli, et al. Expires January 17, 2005 [Page 10]
Internet-Draft SNMP usage for PAA-EP interface July 2004
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.
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 January 17, 2005 [Page 11]
Internet-Draft SNMP usage for PAA-EP interface July 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
the PANA EP configuration:
IPSec Security Policy Database (SPD) MIB:
[I-D.ietf-ipsp-spd-mib] defines a MIB module for configuration of
an IPSec Security Policy Database (SPD). No IPSec or IKE specific
actions are defined within this document.
IPSec IKE Action MIB:
[I-D.ietf-ipsp-ikeaction-mib] defines a MIB module for
configuration of an IKE action within the IPSec 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 a 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 Section
5.2.
The IPSec SPD MIB module (SPD-MIB) 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, 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 SPD-MIB are generic and simply bind a filter to an action.
Filters provided within the SPD-MIB itself are numerous and fairly
complete for most common packet filtering usage but externally
El Mghazli, et al. Expires January 17, 2005 [Page 12]
Internet-Draft SNMP usage for PAA-EP interface July 2004
defined filters are supported.
Below are basic DI-based filters and static actions that are used -
together with the other SPD tables - to enforce binary packet
authorization at the EP:
-- Ipv4/v6 address-based filter:
For Ipv4/v6 address-based filters provisioning, the IPSec 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
* 802.1 UserPriority Match
-- Static Actions:
The actions encapsulated within the SPD-MIB module are basic drop/
accept actions. These are sufficient to perform EP general binary
authorization enforcement at the EP.
5.2 IPSec Access Control
The PANA protocol authenticates the client and also establishes a
El Mghazli, et al. Expires January 17, 2005 [Page 13]
Internet-Draft SNMP usage for PAA-EP interface July 2004
PANA security association between the PANA client and PANA
authentication agent at the end of successful authentication. The
PAA indicates the results of the authentication using the
PANA-Bind-Request (PBR) 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:
1. PANA client (PaC) and PAA mutually authenticate each other using
EAP methods that derive the AAA-Key [I-D.ietf-eap-keying].
2. PaC learns the IP address of the Enforcement point (EP) during
the PANA exchange.
3. PaC learns that the network uses IPSec [RFC2401] for securing the
link between PaC and EP during the PANA exchange (PBR message).
4. PaC configures an IP address address before the PANA protocol
begins (the pre-PANA Address (PRPA), see [I-D.ietf-pana-pana]).
The IPSec IKE Action MIB module (IKEACTION-MIB) works within the
framework of the IPSec 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.
The PAA is then responsible to communicate to EP the following
information before IKE phase 1 exchange begins between PaC and EP:
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.
El Mghazli, et al. Expires January 17, 2005 [Page 14]
Internet-Draft SNMP usage for PAA-EP interface July 2004
The PRPA 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 Key-Id and PANA session ID:
[I-D.ietf-pana-ipsec] states that Pac and EP should use the PANA
session ID concatenated with the AAA-key as the value of the
ID_KEY_ID in aggressive mode for establishing the phase 1 SA.
Section 6 details usage examples that illustrate the way the
IKEACTION-MIB is used for this purpose.
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.
See [I-D.ietf-ipsp-spd-mib] for further details.
El Mghazli, et al. Expires January 17, 2005 [Page 15]
Internet-Draft SNMP usage for PAA-EP interface July 2004
6. EP Configuration Example
Below are usage examples of the IPSec modules in the PANA context.
6.1 General IP-based Access Control
Below is a usage example of the IPSec modules. In this example, we
need to configure the SPD so that EP accepts IP packets coming from/
going to the PaC.
The "EndPoint to Group" table is used to map policy (groupings) onto
an endpoint (EP-ADDR is the IP address) where traffic is to pass by.
Any policy group assigned to an endpoint is then used to control
access to the traffic passing by it.
So far, we define below two policy groups at the EP interface
("EP-SPD-IN" and "EP-SPD-OUT").
spdEndpointToGroupTable.1 =
spdEndGroupDirection = incoming;
spdEndGroupIdentType = IPv4;
spdEndGroupAddress = EP-ADDR;
spdEndGroupName = "EP-SPD-IN";
spdEndpointToGroupTable.2 =
spdEndGroupDirection = outgoing;
spdEndGroupIdentType = IPv4;
spdEndGroupAddress = EP-ADDR;
spdEndGroupName = "EP-SPD-OUT";
Within each of the policy group defined above, we define a rule
dedicated to the treatment of packets coming from/going to "PaC1" and
the EP we are provisioning.
spdGroupContentsTable.2 =
spdGroupContName = "EP-SPD-IN";
spdGroupContPriority = 1;
spdGroupContFilter = spdIpHeaderFilterTable.1;
spdGroupContComponentType = rule;
spdGroupContComponentName = "EP-PaC1-IN";
spdGroupContentsTable.2 =
spdGroupContName = "EP-SPD-OUT";
spdGroupContPriority = 1;
spdGroupContFilter = spdIpHeaderFilterTable.2;
spdGroupContComponentType = rule;
spdGroupContComponentName = "EP-PaC1-OUT";
El Mghazli, et al. Expires January 17, 2005 [Page 16]
Internet-Draft SNMP usage for PAA-EP interface July 2004
We define two filters in the "IP Header filter" table: one match IP
packets coming from the PaC, the other match IP packets going to the
PaC.
spdIpHeaderFilterTable.1 =
spdIpHeadFiltName = "PaC1-IP@ Filter SOURCE";
spdIpHeadFiltType = { sourceAddress ON };
spdIpHeadFiltIPVersion = v4;
spdIpHeadFiltSrcAddressBegin = PaC1-IP@;
spdIpHeadFiltSrcAddressEnd = PaC1-IP@;
spdIpHeaderFilterTable.2 =
spdIpHeadFiltName = "PaC1-IP@ Filter DEST";
spdIpHeadFiltType = { destAddress ON };
spdIpHeadFiltIPVersion = v4;
spdIpHeadFiltSrcAddressBegin = PaC1-IP@;
spdIpHeadFiltSrcAddressEnd = PaC1-IP@;
The "Rule Defininition" table links a rule with a given action in the
SPD action MIB. E.g. the following entries links the two filters
defined above with the "accept" action statically defined in the SPD
MIB (spdStaticActions.3).
spdRuleDefinitionTable.1 =
spdRuleDefName = "PaC1-ACCEPT-IN";
spdRuleDefDescription = "Allow Incoming IP packets from PaC1";
spdRuleDefFilter = spdIpHeaderFilterTable.1;
spdRuleDefFilterNegated = false (default);
spdRuleDefAction = spdStaticActions.3;
spdRuleDefinitionTable.2 =
spdRuleDefName = "PaC1-ACCEPT-OUT";
spdRuleDefDescription = "Allow Outgoing IP packets to PaC1";
spdRuleDefFilter = spdIpHeaderFilterTable.2;
spdRuleDefFilterNegated = false (default);
spdRuleDefAction = spdStaticActions.3;
This means that any packet coming from/going to the PaC is now
allowed to go through the EP (via EP-ADDR endpoint).
6.2 IPSec-based Access Control
In this section we consider the previous configuration set is still
valid. Below is a usage example of SPD-MIB and IKEACTION-MIB.
-- IKE Phase 1 configuration (agressive mode):
We define a rule in policy group "EP-SPD-IN" of the SPD MIB, using
El Mghazli, et al. Expires January 17, 2005 [Page 17]
Internet-Draft SNMP usage for PAA-EP interface July 2004
the "Group contents" table. This rule is dedicated to all IKE phase
1 traffic coming to the EP on this interface:
spdGroupContentsTable.1 =
spdGroupContName = "EP-SPD-IN";
spdGroupContPriority = 1;
spdGroupContFilter = ipiaStaticFilters.1;
spdGroupContComponentType = sub-group;
spdGroupContComponentName = "EP-IKE-Phase1-IN";
And within this IKE-specific policy sub-group we now specify the rule
to apply for the IKE traffic coming from PaC1.
spdGroupContentsTable.2 =
spdGroupContName = "EP-IKE-Phase1-IN";
spdGroupContPriority = 1;
spdGroupContFilter = spdIpHeaderFilterTable.1;
spdGroupContComponentType = rule;
spdGroupContComponentName = "PaC1-IKE-RULE";
The spdIpHeaderFilterTable.1 entry has been defined in the previous
seciton.
The "Rule Defininition" table links a rule with a given action in the
IKE action MIB. This action will be triggereed upon reception at the
EP of an IKE packet coming from PaC1.
spdRuleDefinitionTable.3 =
spdRuleDefName = "PaC1-IKE-RULE";
spdRuleDefDescription = "IPSec Access Control for PaC1";
spdRuleDefFilter = spdIpHeaderFilterTable.1;
spdRuleDefFilterNegated = false (default);
spdRuleDefAction = spdIkeActionTable.1;
The "IKE action" entry below specifies the main parameters for the
IKE exchanges.
ipiaIkeActionTable.1 =
ipiaIkeActName = "PaC1-IKE";
ipiaIkeActParametersName = "SA-PaC1";
ipiaIkeActThresholdDerivedKeys = 100 (default);
ipiaIkeActExchangeMode = aggressive;
ipiaIkeActAgressiveModeGroupId = xxx [Diffie-Hellman values];
ipiaIkeActIdentityType = id_Key_Id;
ipiaIkeActIdentityContext = "PANA";
ipiaIkeActPeerName = "PaC1";
ipiaSaNegotiationParametersTable.1 =
El Mghazli, et al. Expires January 17, 2005 [Page 18]
Internet-Draft SNMP usage for PAA-EP interface July 2004
ipiaSaNegParamName = "SA-PaC1";
ipiaSaNegParamMinLifetimeSecs = xxx;
ipiaSaNegParamMinLifetimeKB = xxx;
ipiaSaNegParamRefreshThreshSecs = xxx;
ipiaSaNegParamRefreshThresholdKB = xxx;
ipiaSaNegParamIdleDurationSecs = xxx;
The "Peer Identity" table specifically informs the EP on the value of
the idKeyId to use in IKE messages with PaC1:
ipiaPeerIdentityFilterTable.1 =
ipiaPeerIdFiltName = "PaC1";
ipiaPeerIdFiltIdentityType = id_key_id;
ipiaPeerIdFiltIdentityValue = "PANA-Session-Id|PANA-Key-Id";
The following entry links a given identity (PaC1) with an entry in
the "Credentials" table.
ipiaIkeIdentityTable.1 =
spdEndGroupIdentType = IPv4;
spdEndGroupAddress = EP-ADDR;
ipiaIkeActIdentityType = id_key_id;
ipiaIkeActIdentityContext = PANA;
ipiaIkeIdCredentialName = "PaC1-PSK";
Finally the pre-shared key derivated at the PAA is set here:
ipiaCredentialFilterTable.1 =
ipiaCredFiltName = "PaC1-PSK";
ipiaCredFiltCredentialType = sharedSecret;
ipiaCredFiltMatchFieldName = none;
ipiaCredFiltMatchFieldValue = "PSK-from-PAA";
El Mghazli, et al. Expires January 17, 2005 [Page 19]
Internet-Draft SNMP usage for PAA-EP interface July 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-EP
interface requirements.
7.1 PANA MIB Overview
o IEEE 802 filters
o New PaC notification
o Maximum amount of units notification (TBD)
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
ORGANIZATION
El Mghazli, et al. Expires January 17, 2005 [Page 20]
Internet-Draft SNMP usage for PAA-EP interface July 2004
"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
--
--
-- The IEEE 802 Filter Table
El Mghazli, et al. Expires January 17, 2005 [Page 21]
Internet-Draft SNMP usage for PAA-EP interface July 2004
--
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))
MAX-ACCESS not-accessible
El Mghazli, et al. Expires January 17, 2005 [Page 22]
Internet-Draft SNMP usage for PAA-EP interface July 2004
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
MAC SA matches the physical address specified by this
El Mghazli, et al. Expires January 17, 2005 [Page 23]
Internet-Draft SNMP usage for PAA-EP interface July 2004
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 January 17, 2005 [Page 24]
Internet-Draft SNMP usage for PAA-EP interface July 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 January 17, 2005 [Page 25]
Internet-Draft SNMP usage for PAA-EP interface July 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 January 17, 2005 [Page 26]
Internet-Draft SNMP usage for PAA-EP interface July 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 January 17, 2005 [Page 27]
Internet-Draft SNMP usage for PAA-EP interface July 2004
8. Open Issues
8.1 MIB Usage Example
The MIB usage example (Section 6) needs to be further developped.
8.2 L2 Filtering Support
As stated above, the EP enforces binary authorization by filtering
data traffic on the basis of the Device Identifier (DI) of the PaC.
The DI could be either a IPv4/6 address or a link-layer address. The
IP case is fully supported by the current version of the document.
However, in terms of L2 filetring, the present PANA-specific MIB
controls IEEE 802 traffic only.
In [I-D.ietf-pana-pana] (section 6.5.2), the specification of the
Device-Id AVP says the Device-Id AVP (code 1025) is of Address Type
[RFC3588]. The content for link-layer addresses is expected to be
specified in specific documents that describe how IP operates over
different link-layers. For instance, [RFC2464].
The PANA working group must define a short list of L2 address
filtering that the PANA-specific defined in this document must
support, in addition to the 802 table defined here.
8.3 L2 Protection Support
[I-D.ietf-pana-framework] envisages the case, where enabling
link-layer ciphering or network-layer ciphering might rely on PANA
authentication. The user and network then have to make sure an
appropriate EAP method that can generate required keying materials is
used. Once the keying material is available, it needs to be provided
to the EP(s) for use with ciphering.
Network-layer ciphering, i.e., IPsec, including IKE configuration is
fully supported in the present document. However link-layer ciphers
are not supported yet. The PANA working group must define the L2
techniques for realizing this feature and the present document will
take it into account.
8.4 Security Section
The Security section will be finalized, once the PANA-specific MIB
objects definition terminated.
El Mghazli, et al. Expires January 17, 2005 [Page 28]
Internet-Draft SNMP usage for PAA-EP interface July 2004
9. 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 January 17, 2005 [Page 29]
Internet-Draft SNMP usage for PAA-EP interface July 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 January 17, 2005 [Page 30]
Internet-Draft SNMP usage for PAA-EP interface July 2004
10. 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 January 17, 2005 [Page 31]
Internet-Draft SNMP usage for PAA-EP interface July 2004
11. References
11.1 Normative References
[I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-04 (work in
progress), May 2004.
[I-D.ietf-pana-requirements]
Yegin, A. and Y. Ohba, "Protocol for Carrying
Authentication for Network Access (PANA)Requirements",
draft-ietf-pana-requirements-08 (work in progress), June
2004.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA enabling IPsec based Access
Control", draft-ietf-pana-ipsec-03 (work in progress), May
2004.
[I-D.ietf-pana-threats-eval]
Parthasarathy, M., "Protocol for Carrying Authentication
and Network Access Threat Analysis and Security
Requirements", draft-ietf-pana-threats-eval-06 (work in
progress), June 2004.
[I-D.ietf-pana-framework]
Jayaraman, P., "PANA Framework",
draft-ietf-pana-framework-00 (work in progress), May 2004.
[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-spd-mib]
Hardaker, W., "IPsec Security Policy Database
Configuration MIB", draft-ietf-ipsp-spd-mib-00 (work in
progress), January 2004.
[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.
[I-D.ietf-aaa-diameter-cc]
Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.
Hakala, "Diameter Credit-control Application",
El Mghazli, et al. Expires January 17, 2005 [Page 32]
Internet-Draft SNMP usage for PAA-EP interface July 2004
draft-ietf-aaa-diameter-cc-05 (work in progress), May
2004.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-08 (work in progress), June 2004.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-02 (work in
progress), June 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
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 January 17, 2005 [Page 33]
Internet-Draft SNMP usage for PAA-EP interface July 2004
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
11.2 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.
Authors' Addresses
Yacine El Mghazli (Editor)
Alcatel
Route de Nozay
Marcoussis 91460
France
EMail: yacine.el_mghazli@alcatel.fr
Yoshihiro Ohba
Toshiba America Research, Inc.
1, Telcordia Drive
Piscataway, NJ 08854
USA
EMail: yohba@tari.toshiba.com
Julien Bournelle
GET/INT
9, rue Charles Fourier
Evry 91011
France
EMail: julien.bournelle@int-evry.fr
El Mghazli, et al. Expires January 17, 2005 [Page 34]
Internet-Draft SNMP usage for PAA-EP interface July 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 January 17, 2005 [Page 35]
Internet-Draft SNMP usage for PAA-EP interface July 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 January 17, 2005 [Page 36]
