[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-pana-snmp

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/