[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
   PANA WG                                            Yacine El Mghazli
   Internet Draft                                               Alcatel
   Category: STD
   Document: draft-yacine-pana-snmp-00.txt
   Expires: May 2004                                      December 2003
 
 
                                   PANA
                     SNMP usage for PAA-2-EP interface
 
 
 
  Status of this Memo
 
 
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [STD].
 
   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.
 
  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
   extensions needed to use SNMP as the PAA-2-EP protocol.
 
 
 
 
 
 
 El Mghazli              Expires - June 2004                 [Page 1]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
  Conventions used in this document
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
 
  Table of Contents
 
   1. Glossary.......................................................3
   2. Introduction...................................................3
      2.1. Scope.....................................................4
   3. The Internet-Standard Management Framework.....................4
   4. SNMP Applicability with the PANA framework.....................5
      4.1. SNMPv3 General applicability..............................5
      4.2. Compliancy of SNMP against the PAA-EP requirements........6
       4.2.1. EP Configuration information...........................6
       4.2.2. One-to-many PAA-EP relation............................6
       4.2.3. Secure Communication...................................6
       4.2.4. New PaC Notification...................................6
   5. Applicability of existing MIB modules..........................7
      5.1. IPSec Policy configuration MIB............................7
       5.1.1. IPSec Access Control...................................7
       5.1.2. General Access Control.................................8
       5.1.3. New PaC Notification...................................9
      5.2. Differentiated Services MIB..............................10
   6. PANA extension to the IPSec MIB...............................10
      6.1. PANA MIB Overview........................................10
      6.2. PANA-specific objects definition.........................11
   7. Security Considerations.......................................19
   References.......................................................20
      Normative References..........................................20
      Informative References........................................21
   Acknowledgements.................................................21
   Author's Addresses...............................................22
   Full Copyright Statement.........................................23
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 El Mghazli              Expires - June 2004                 [Page 2]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
  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.
 
 
 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),
   or on another subnet in the access domain (e.g., gateway to the
   Internet, depending on the network architecture). 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
 
 
 El Mghazli              Expires - June 2004                 [Page 3]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   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.
 
   Section 5 details the applicability of existing MIB modules to the EP
   configuration. Some MIB modules were found to have general
   applicability and varying levels of re-usability for PANA EP
   configuration using SNMP.
 
   Section 6 defines additional PANA-specific objects that extend the
   IPSec MIB module in order to entirely satisfy the PAA-2-EP interface
   requirements.
 
   Finally, section 7 addresses the security considerations
 
 
 3. The Internet-Standard Management Framework
 
   For a detailed overview of the documents that describe the current
   Internet-Standard Management FramewFork, please refer to section 7 of
   RFC 3410 [SNMP-FRWK].
 
   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 [SMIv2], STD 58, RFC 2579 [SMI-TC] and STD 58, RFC 2580
   [RFC2580].
 
   This section provides a general statement with regards to the
   applicability of SNMP as the PAA-EP protocol. This evaluation 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.
 
 
 
 
 
 El Mghazli              Expires - June 2004                 [Page 4]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
 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 [SNMP-ARCH], 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
 
 
 
 El Mghazli              Expires - June 2004                 [Page 5]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   operational parameters and statistics, which are defined in MIB
   modules.
 
 
 4.2. Compliancy of SNMP against the PAA-EP requirements
 
   [PAA-EP-EVAL] gives further details about the choice of SNMP as the
   PAA-2-EP protocol.
 
   The following section illustrate how all the requirements as
   described in [PANA-REQ] are fully supported by SNMP:
 
 
 4.2.1.
        EP Configuration information
 
   The PAA-2-EP protocol must carry DI-based filters and keying
   material. Using SNMP to configure the EPs, one can re-use existing
   MIBs, this detailed in section 5.
 
   Additional PANA-specific objects may be needed and are defined in
   section 6.
 
 
 4.2.2.
        One-to-many PAA-EP relation
 
   This means that there might be multiple EPs per PAA. The SNMP
   framework [SNMP-FRWK] 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], 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 7 for further information on this subject.
 
 
 4.2.4.
       New PaC Notification
 
   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.
 
 
 El Mghazli              Expires - June 2004                 [Page 6]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
 
   The PAA-2-EP protocol may allow the EP to notify a new PaC to the
   PAA. See section 5.1.3 for details on how new and existing SNMP
   objects provide this feature.
 
 
 5. Applicability of existing MIB modules
 
   This section details the applicability of existing MIB modules to the
   EP configuration. The following existing MIB modules were found to
   have general applicability and varying levels of re-usability for
   PANA EP configuration, when PAA and EP are not co-located:
 
     . IPsec Policy Configuration MIB [IPSEC-MIB]
     . Differentiated Services MIB [DS-MIB]
 
 
 5.1. IPSec Policy configuration MIB
 
   The IPSec Configuration MIB [IPSEC-MIB] defines a configuration MIB
   module for IPSec [IPSEC]/IKE [IKE] policy. It does not define MIB
   modules for monitoring the state of an IPsec device. It does not
   define MIB modules for configuring other policy related actions. The
   purpose of this MIB module is to allow administrators to be able to
   configure policy with respect to the IPsec/IKE protocols. However,
   some of the packet filtering and matching of conditions to actions is
   of a more general nature than IPsec only. It is possible to add other
   packet transforming actions to this MIB module if those actions
   needed to be performed conditionally on filtered traffic.
 
   The IPSec Configuration MIB is a large MIB designed to support IPSec
   and IKE management in a policy and rule oriented fashion. The MIB
   module is divided into 3 portions (Rules, Filters, Actions).
   Specifically, the IPSec MIB provides a generic mechanism for
   performing packet processing based on a rule set. Rules within the
   IPSec Configuration MIB are generic and simply bind a filter to an
   action. Filters provided within the IPSec MIB itself are numerous and
   fairly complete for most common packet filtering usage but externally
   defined filters are supported. The actions encapsulated within the
   IPSec MIB are mostly related to IKE and IPSec.
 
 
 5.1.1.
       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
 
 
 El Mghazli              Expires - June 2004                 [Page 7]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   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
   [PANA] does not discuss any details of IPsec [IPSEC] SA
   establishment. Indeed, [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 [PANA-THREATS].
 
   In this particular context, one assumes that the following have
   already happened before the IPSec SA is established:
 
     1. PANA client (PaC) learns the IP address of the Enforcement Point
        (EP) during the PANA exchange.
     2. PaC learns that the network uses IPsec [IPSEC] for securing the
        link between PaC and EP during the PANA exchange.
     3. PaC has already acquired an IP address and EP knows about the IP
        address of the PaC, before the IKE exchange starts. If IPv6 is
        being used, the EP needs to know both the global address and the
        link-local address of the PaC.
 
   The PAA is responsible to communicate to EP the following before IKE
   phase 1 exchange begins:
          . the IKE pre-shared key,
          . the IP address of the PaC,
          . and the PANA session ID (for pre-shared key derivation).
 
   When PAA and EP are not co-located, the PAA-2-EP protocol MUST carry
   this information. SNMP, together with the IPSec Configuration MIB
   enable such configurations without any modification. The whole
   behaviour of the EP can be configured by provisioning the IPSec MIB
   objects.
 
   For example, the ipspIkeActionTable contains a list of the parameters
   used for an IKE phase 1 SA negotiation. For further detail, please
   refer directly to [IPSEC-MIB].
 
 
 5.1.2.
       General Access Control
 
   More generally, the PAA-2-EP protocol must carry DI-based filters in
   order to control and police the network access of a PaC. According to
   the definition of the Device Identifier in [PANA-REQ], such filters,
   depending on the access technology, might contain any of IP address
   or link-layer address of a connected device.
 
 
 
 
 El Mghazli              Expires - June 2004                 [Page 8]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   Do note also that keying material might be provisioned for the
   particular case where access control is performed using IPSec ([PANA-
   IPSEC], see the previous section 5.1.1).
 
   For Ipv4/v6 address-based filters provisioning, the IPSec
   configuration MIB [IPSEC-MIB] provides means to filter the traffic
   based on the IP header information. IPSec MIB-defined
   IpspIpHeaderFilter provides such facilities: one can define the
   various tests that are used when evaluating a given IP packet. 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. The various tests definable in this table
   are as follows:
     . Source Address
     . Destination Address
     . Source Port Range
     . Destination Port Range
     . Protocol
     . ipv6 Flow Label (Ipv6 only)
 
   For Layer 2 address-based classification, additional filters might be
   designed if needed. Section 6 gives an example of the definition of a
   new IEEE 802-based filter, which may be useful in appropriate access
   networks.
 
   IPSec Compound filter and action sequences can be defined for
   administrators that need more complex or need to chain multiple
   actions together based on success/failure states. The compound
   mechanisms are also generic and let PANA-specific MIB elements to be
   used within the compound bindings.
 
 5.1.3.
       New PaC Notification
 
   The IPSec 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 6 defines a new SNMP notification, which aims at satisfying
   this requirement. It re-uses existing notification variable objects
   pre-defined in the IPSec MIB.
 
   This "New PaC Notification" (panaNewPacNotification) is triggered by
   the detection by the EP of traffic coming from an unauthorized
   source. The objects sent must include the ipspIPSourceType,
   ipspIPSourceAddress, ipspIPDestinationType, and
   ipspIPDestinationAddress objects to indicate the packet source and
 
 
 El Mghazli              Expires - June 2004                 [Page 9]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   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 outbond through the endpoint. See [IPSEC-MIB] for further
   details.
 
   Such a notification is able to trigger the sending of PANA-Start-
   Request message from the PAA to newly identified PaC.
 
 
 5.2. Differentiated Services MIB
 
   The DiffServ MIB [DS-MIB] is a very powerful and flexible MIB module,
   however, this flexibility may be too broad in general for the PANA
   specific needs.
 
   However, the DiffServ model of using different tables for data path
   elements could be useful for EP configuration. The DiffServ MIB
   module connects datapath building blocks (classifiers, meters, static
   actions, etc.) together.
 
   The use of RowPointers as connectors in the DiffServ MIB allows for
   the simple extension of the MIB. The RowPointers, whether "next" or
   "specific", may point to Entries defined in other MIB modules. This
   mechanism can point to other, possibly vendor-specific, configuration
   MIB modules.
 
   The Diffserv MIB natively provides IP Header-based filters and
   Drop/Accept basic actions. It can be sufficient in many situations.
 
   Anyway, the remaining of the document does not further study the
   DiffServ MIB module applicability to PANA.
 
 
 6. PANA extension to the IPSec 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.1.
 
   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.
 
 
 6.1. PANA MIB Overview
 
     . 802 filters
 
 
 El Mghazli              Expires - June 2004                [Page 10]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
     . New PaC Notification
 
 
 6.2. PANA-specific objects definition
 
   PANA-MIB DEFINITIONS ::= BEGIN
 
   IMPORTS
 
   MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE
                                 FROM SNMPv2-SMI
 
   RowStatus, PhysAddress
                                 FROM SNMPv2-TC
 
   MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
                                 FROM SNMPv2-CONF
 
   IpspMib, ipspActionExecuted, ipspIPInterfaceType,
   ipspIPInterfaceAddress, ipspIPSourceType, ipspIPSourceAddress,
   ipspIPDestinationType, ipspIPDestinationAddress, ipspPacketDirection
                                 FROM IPSEC-POLICY-MIB;
 
   --
   -- Module identity
   --
 
   panaMIB MODULE-IDENTITY
     LAST-UPDATED
        "200210310000Z"            -- 31 October 2003
     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 Configuration 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
        "200210310000Z"            -- 31 October 2003
     DESCRIPTION
        "Initial version, published as draft-yacine-pana-
 
 
 El Mghazli              Expires - June 2004                [Page 11]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
         paa2ep-snmp-00.txt"
   ::= { ipspMib 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
   --
 
 
   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
 
 
 El Mghazli              Expires - June 2004                [Page 12]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
           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,
           pana802FilterDstAddrMask     PhysAddress,
           pana802FilterSrcAddr         PhysAddress,
           pana802FilterSrcAddrMask     PhysAddress,
           pana802FilterVlanId          Integer32,
           pana802FilterVlanTagRequired INTEGER,
           pana802FilterEtherType       Integer32,
           pana802FilterUserPriority    BITS,
           pana802FiltLastChanged       TimeStamp,
           pana802FiltStorageType       StorageType,
           pana802FiltRowStatus         RowStatus
 
   }
 
   pana802FilterNamer OBJECT-TYPE
       SYNTAX         SnmpAdminString (SIZE(1..32))
       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.
 
 
 El Mghazli              Expires - June 2004                [Page 13]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
            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 }
 
   pana802FilterDstAddrMask OBJECT-TYPE
       SYNTAX         PhysAddress
       MAX-ACCESS     read-create
       STATUS         current
       DESCRIPTION
          "This object specifies the bits in a 802 destination address
           that should be considered when performing a 802 DA
           comparison against the address specified in the
           pana802FilterDstAddr object.
           The value of this object represents a mask that is logically
           and'ed with the 802 DA in received frames to derive the
           value to be compared against the pana802FilterDstAddr
           address. A zero bit in the mask thus means that the
           corresponding bit in the address always matches. The
           pana802FilterDstAddr value must also be masked using this
           value prior to any comparisons.
           The length of this object in octets must equal the length in
           octets of the pana802FilterDstAddr. Note that a mask with no
           bits set (i.e., all zeroes) effectively wildcards the
           pana802FilterDstAddr object."
 
       ::= { pana802FilterEntry 4 }
 
   pana802FilterSrcAddr OBJECT-TYPE
       SYNTAX         PhysAddress
       MAX-ACCESS     read-create
       STATUS         current
       DESCRIPTION
          "The 802 MAC address against which the 802 MAC SA of
 
 
 El Mghazli              Expires - June 2004                [Page 14]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
           incoming traffic streams will be compared. Frames whose 802
           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 5 }
 
   pana802FilterSrcAddrMask OBJECT-TYPE
       SYNTAX         PhysAddress
       MAX-ACCESS     read-create
       STATUS         current
       DESCRIPTION
          "This object specifies the bits in a 802 MAC source address
           that should be considered when performing a 802 MAC SA
           comparison against the address specified in the
           pana802FilterSrcAddr object.
           The value of this object represents a mask that is logically
           and'ed with the 802 MAC SA in received frames to derive the
           value to be compared against the pana802FilterSrcAddr
           address. A zero bit in the mask thus means that the
           corresponding bit in the address always matches. The
           pana802FilterSrcAddr value must also be masked using this
           value prior to any comparisons.
           The length of this object in octets must equal the length in
           octets of the pana802FilterSrcAddr. Note that a mask with no
           bits set (i.e., all zeroes) effectively wildcards the
           pana802FilterSrcAddr object."
       ::= { pana802FilterEntry 6 }
 
   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 7 }
 
   pana802FilterVlanTagRequired OBJECT-TYPE
       SYNTAX         INTEGER {
                         taggedOnly(1),
                         priorityTaggedPlus(2),
 
 
 El Mghazli              Expires - June 2004                [Page 15]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
                         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 8 }
 
   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 9 }
 
   pana802FilterUserPriority OBJECT-TYPE
       SYNTAX         BITS {
 
 
 El Mghazli              Expires - June 2004                [Page 16]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
                           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
           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 10 }
 
   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 11 }
 
   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 12 }
 
 
 
 El Mghazli              Expires - June 2004                [Page 17]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   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 13 }
 
 
   --
   --
   -- Notification objects information
   --
   --
 
   panaNotifications OBJECT IDENTIFIER ::=
      { panaNotificationObjects 0 }
 
   panaNewPacNotification NOTIFICATION-TYPE
     OBJECTS { ipspActionExecuted, ipspIPInterfaceType,
               ipspIPInterfaceAddress,
               ipspIPSourceType, ipspIPSourceAddress,
               ipspIPDestinationType,
               ipspIPDestinationAddress,
               ipspPacketDirection }
     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 }
 
 
   --
   --
 
 
 El Mghazli              Expires - June 2004                [Page 18]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   -- Conformance information
   --
   --
 
   -- TBD.
 
   END
 
 
 7. 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>
 
 
 
 
 El Mghazli              Expires - June 2004                [Page 19]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   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 [SNMP-FRWK], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   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.
 
 
 References
 
 Normative References
 
   [PANA] D. Forsberg, Y. Ohba, B. Pati, H. Tschofenig, A. Yegin,
      "Protocol for Carrying Authentication for Network Access
      (PANA)"(draft-ietf-pana-pana-02.txt).
 
   [PANA-REQ] R. Penno, et al., "Protocol for Carrying Authentication
      for Network Access (PANA) Requirements and Terminology" (draft-
      ietf-pana-requirements-07.txt).
 
   [PANA-IPSEC] Parthasarathy, M., "PANA enabling IPsec based Access
      Control", draft-ietf-pana-ipsec-00 (work in progress), October
      2003.
 
   [PANA-THREATS] Parthasarathy, M., "PANA Threat Analysis and security
      requirements", draft-ietf-pana-threats-eval-04 (work in progress),
      May 2003.
 
   [USM] 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.
 
   [IPSEC-MIB] Baer, M., Charlet, R., Hardaker, W., Story, R., Wang, C.,
      "IPsec Policy Configuration MIB module", draft-ietf-ipsp-ipsec-
      conf-mib-06.txt, March, 2003.
 
 
 
 
 El Mghazli              Expires - June 2004                [Page 20]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
   [DS-MIB] Baker, F., Chan, K., Smith, A., "Management Information Base
      for the Differentiated Services Architecture", RFC 3289, May 2002.
 
   [IPSEC] Kent, S., and Atkinson, R., "Security Architecture for the
      Internet Protocol", RFC 2401, November 1998.
 
   [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)",
      RFC 2409, November 1998.
 
   [STD] Bradner, S., "The Internet Standards Process -- Revision 3",
      BCP 9, RFC 2026, October 1996.
 
   [SNMP-FRWK] Case, J., Mundy, R., Partain, D. and B. Stewart,
      "Introduction and Applicability Statements for Internet-Standard
      Management Framework", RFC 3410, December 2002.
 
   [SNMP-ARCH] 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.
 
   [SMIv2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
      Rose, M. and S. Waldbusser, "Structure of Management Information
      Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
 
   [SMI-TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
      Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD
      58, RFC 2579, April 1999.
 
   [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
      Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2",
      STD 58, RFC 2580, April 1999.
 
 
 Informative References
 
   [PAA-EP-EVAL] Y. El Mghazli , "PANA PAA-EP Protocol Considerations"
      (draft-yacine-pana-paa2ep-prot-eval-00.txt).
 
   [PAA-EP-REQ] Y. El Mghazli , "PANA PAA-EP Protocol Requirements"
      (draft-yacine-pana-paa-ep-reqs-00.txt).
 
 
 Acknowledgements
 
   This document leverages on similar works done in the MIDCOM working
   group. Thanks to the authors of those IDs.
 
 
 El Mghazli              Expires - June 2004                [Page 21]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
 
   The author would like to thank Julien Bournelle for his grateful
   help, comments and feedback during the edition of this document.
 
 
 Author's Addresses
 
   Yacine El Mghazli
   Alcatel
   Route de Nozay
   91460 Marcoussis cedex
   Phone: +33 (0)1 69 63 41 87
   Email: yacine.el_mghazli@alcatel.fr
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 El Mghazli              Expires - June 2004                [Page 22]


 Internet Draft     draft-yacine-pana-snmp-00.txt       December 2003
 
 
 Full Copyright Statement
 
   "Copyright (C) The Internet Society (2003). 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 assigns.
 
   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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 El Mghazli              Expires - June 2004                [Page 23]