One document matched: draft-yacine-pana-snmp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 21:08:52 |