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: -- 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: 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]