idnits 2.17.1 draft-yacine-pana-snmp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 7438 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'PAA-EP-REQ' is defined on line 979, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-02 == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-07 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-requirements (ref. 'PANA-REQ') == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-00 == Outdated reference: A later version (-07) exists of draft-ietf-pana-threats-eval-04 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-threats-eval (ref. 'PANA-THREATS') -- Possible downref: Normative reference to a draft: ref. 'IPSEC-MIB' ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 3410 (ref. 'SNMP-FRWK') Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PANA WG Yacine El Mghazli 2 Internet Draft Alcatel 3 Category: STD 4 Document: draft-yacine-pana-snmp-00.txt 5 Expires: May 2004 December 2003 7 PANA 8 SNMP usage for PAA-2-EP interface 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [STD]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The PANA Authentication Agent (PAA) does not necessarily act as an 33 Enforcement Point (EP) to prevent unauthorized access or usage of the 34 network. When a PANA Client (PaC) successfully authenticates itself 35 to the PAA, EP(s) (e.g., access routers) will need to be suitably 36 notified. The PANA working group mandates the use of Simple Network 37 Management Protocol (SNMP) to deliver the authorization information 38 to one or more EPs when the PAA is separated from EPs. 40 The present document provides the necessary information and 41 extensions needed to use SNMP as the PAA-2-EP protocol. 43 Conventions used in this document 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in [RFC2119]. 49 Table of Contents 51 1. Glossary.......................................................3 52 2. Introduction...................................................3 53 2.1. Scope.....................................................4 54 3. The Internet-Standard Management Framework.....................4 55 4. SNMP Applicability with the PANA framework.....................5 56 4.1. SNMPv3 General applicability..............................5 57 4.2. Compliancy of SNMP against the PAA-EP requirements........6 58 4.2.1. EP Configuration information...........................6 59 4.2.2. One-to-many PAA-EP relation............................6 60 4.2.3. Secure Communication...................................6 61 4.2.4. New PaC Notification...................................6 62 5. Applicability of existing MIB modules..........................7 63 5.1. IPSec Policy configuration MIB............................7 64 5.1.1. IPSec Access Control...................................7 65 5.1.2. General Access Control.................................8 66 5.1.3. New PaC Notification...................................9 67 5.2. Differentiated Services MIB..............................10 68 6. PANA extension to the IPSec MIB...............................10 69 6.1. PANA MIB Overview........................................10 70 6.2. PANA-specific objects definition.........................11 71 7. Security Considerations.......................................19 72 References.......................................................20 73 Normative References..........................................20 74 Informative References........................................21 75 Acknowledgements.................................................21 76 Author's Addresses...............................................22 77 Full Copyright Statement.........................................23 79 1. Glossary 81 PANA Protocol for Carrying Authentication for Network Access. 83 PaC (PANA Client): 85 The client side of the protocol that resides in the host device, 86 which is responsible for providing the credentials to prove its 87 identity for network, access authorization. 89 DI (Device Identifier): 91 The identifier used by the network as a handle to control and 92 police the network access of a client. Depending on the access 93 technology, this identifier might contain any of IP address, link- 94 layer address, switch port number, etc. of a connected device. 96 PAA (PANA Authentication Agent): 98 The access network side entity of the protocol whose responsibility 99 is to verify the credentials provided by a PANA client and grant 100 network access service to the device associated with the client and 101 identified by a DI. 103 EP (Enforcement Point): 105 A node on the access network where per-packet enforcement policies 106 (i.e., filters) are applied on the inbound and outbound traffic of 107 client devices. Information such as DI and (optionally) 108 cryptographic keys are provided by PAA per client for constructing 109 filters on the EP. 111 2. Introduction 113 Client access authentication should be followed by access control to 114 make sure only authenticated and authorized clients can send and 115 receive IP packets via access network. Access control can involve 116 setting access control lists on the enforcement points. 117 Identification of clients, which are authorized to access the 118 network, is done by the PANA protocol exchange. 120 PANA does not assume that the PAA is always co-located with the 121 EP(s). Network access enforcement can be provided by one or more 122 nodes on the same IP subnet as the client (e.g., multiple routers), 123 or on another subnet in the access domain (e.g., gateway to the 124 Internet, depending on the network architecture). When the PAA and 125 the EP(s) are separated, there needs to be another transport for 126 client provisioning. This PAA-2-EP transport is needed to create 127 access control lists to allow authenticated and authorized clients' 128 traffic through the EPs. 130 The present document provides the necessary information and 131 extensions needed to use SNMP as the PAA-2-EP protocol. 133 2.1. Scope 135 The next section 3 gives references for the SNMP framework. 137 Then section 4 provides a general statement with regards to the 138 applicability of SNMP as the PAA-2-EP protocol. 140 Section 5 details the applicability of existing MIB modules to the EP 141 configuration. Some MIB modules were found to have general 142 applicability and varying levels of re-usability for PANA EP 143 configuration using SNMP. 145 Section 6 defines additional PANA-specific objects that extend the 146 IPSec MIB module in order to entirely satisfy the PAA-2-EP interface 147 requirements. 149 Finally, section 7 addresses the security considerations 151 3. The Internet-Standard Management Framework 153 For a detailed overview of the documents that describe the current 154 Internet-Standard Management FramewFork, please refer to section 7 of 155 RFC 3410 [SNMP-FRWK]. 157 Managed objects are accessed via a virtual information store, termed 158 the Management Information Base or MIB. MIB objects are generally 159 accessed through the Simple Network Management Protocol (SNMP). 160 Objects in the MIB are defined using the mechanisms defined in the 161 Structure of Management Information (SMI). This memo specifies a MIB 162 module that is compliant to the SMIv2, which is described in STD 58, 163 RFC 2578 [SMIv2], STD 58, RFC 2579 [SMI-TC] and STD 58, RFC 2580 164 [RFC2580]. 166 This section provides a general statement with regards to the 167 applicability of SNMP as the PAA-EP protocol. This evaluation of SNMP 168 is specific to SNMPv3, which provides the security required for PANA 169 usage. SNMPv1 and SNMPv2c would be inappropriate for PANA since they 170 have been declared Historic, and because their messages have only 171 trivial security. 173 4. SNMP Applicability with the PANA framework 175 This section provides a general statement with regards to the 176 applicability of SNMP as the PAA-2-EP protocol. This analysis of SNMP 177 is specific to SNMPv3, which provides the security required for PANA 178 usage. SNMPv1 and SNMPv2c would be inappropriate for PANA since they 179 have been declared Historic, and because their messages have only 180 trivial security. 182 4.1. SNMPv3 General applicability 184 The primary advantages of SNMPv3 are that it is a mature, well 185 understood protocol, currently deployed in various scenarios, with 186 mature toolsets available for SNMP managers and agents. 188 Application intelligence is captured in MIB modules, rather than in 189 the messaging protocol. MIB modules define a data model of the 190 information that can be collected and configured for a managed 191 functionality. The SNMP messaging protocol transports the data in a 192 standardized format without needing to understand the semantics of 193 the data being transferred. The endpoints of the communication 194 understand the semantics of the data. 196 Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly 197 due to variations in configuration requirements across vendors, few 198 MIB modules have been developed that enable standardized 199 configuration of managed devices across vendors. Since monitoring can 200 be done using only a least-common-denominator subset of information 201 across vendors, many MIB modules have been developed to provide 202 standardized monitoring of managed devices. As a result, SNMP has 203 been used primarily for monitoring rather than for configuring 204 network nodes. 206 SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c 207 versions. Specifically, SNMPv3 shares the separation of data modeling 208 (MIBs) from the protocol to transfer data, so all existing MIBs can 209 be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, and it 210 shares operations and transport with SNMPv2c. The major difference 211 between SNMPv3 and earlier versions is the addition of strong message 212 security and controlled access to data. 214 SNMPv3 uses the architecture detailed in [SNMP-ARCH], where all SNMP 215 entities are capable of performing certain functions, such as the 216 generation of requests, response to requests, the generation of 217 asynchronous notifications, the receipt of notifications, and the 218 proxy-forwarding of SNMP messages. SNMP is used to read and 219 manipulate virtual databases of managed-application-specific 220 operational parameters and statistics, which are defined in MIB 221 modules. 223 4.2. Compliancy of SNMP against the PAA-EP requirements 225 [PAA-EP-EVAL] gives further details about the choice of SNMP as the 226 PAA-2-EP protocol. 228 The following section illustrate how all the requirements as 229 described in [PANA-REQ] are fully supported by SNMP: 231 4.2.1. 232 EP Configuration information 234 The PAA-2-EP protocol must carry DI-based filters and keying 235 material. Using SNMP to configure the EPs, one can re-use existing 236 MIBs, this detailed in section 5. 238 Additional PANA-specific objects may be needed and are defined in 239 section 6. 241 4.2.2. 242 One-to-many PAA-EP relation 244 This means that there might be multiple EPs per PAA. The SNMP 245 framework [SNMP-FRWK] clearly states that an SNMP manager (PAA) can 246 communicate simultaneously with several agents (EPs). 248 4.2.3. 249 Secure Communication 251 SNMPv3 includes the User-based Security Model [USM], which defines 252 three standardized methods for providing authentication, 253 confidentiality, and integrity. Additionally, USM has specific 254 built-in mechanisms for preventing replay attacks including unique 255 protocol engine IDs, timers and counters per engine and time windows 256 for the validity of messages. 258 See section 7 for further information on this subject. 260 4.2.4. 261 New PaC Notification 263 PaC may also choose to start sending packets before getting 264 authenticated. In that case, the network should detect this and the 265 PAA must send an unsolicited PANA-Start-Request message to PaC. EP is 266 the node that can detect such activity. In case they are separate, 267 there needs to be an explicit message to prompt PAA. 269 The PAA-2-EP protocol may allow the EP to notify a new PaC to the 270 PAA. See section 5.1.3 for details on how new and existing SNMP 271 objects provide this feature. 273 5. Applicability of existing MIB modules 275 This section details the applicability of existing MIB modules to the 276 EP configuration. The following existing MIB modules were found to 277 have general applicability and varying levels of re-usability for 278 PANA EP configuration, when PAA and EP are not co-located: 280 . IPsec Policy Configuration MIB [IPSEC-MIB] 281 . Differentiated Services MIB [DS-MIB] 283 5.1. IPSec Policy configuration MIB 285 The IPSec Configuration MIB [IPSEC-MIB] defines a configuration MIB 286 module for IPSec [IPSEC]/IKE [IKE] policy. It does not define MIB 287 modules for monitoring the state of an IPsec device. It does not 288 define MIB modules for configuring other policy related actions. The 289 purpose of this MIB module is to allow administrators to be able to 290 configure policy with respect to the IPsec/IKE protocols. However, 291 some of the packet filtering and matching of conditions to actions is 292 of a more general nature than IPsec only. It is possible to add other 293 packet transforming actions to this MIB module if those actions 294 needed to be performed conditionally on filtered traffic. 296 The IPSec Configuration MIB is a large MIB designed to support IPSec 297 and IKE management in a policy and rule oriented fashion. The MIB 298 module is divided into 3 portions (Rules, Filters, Actions). 299 Specifically, the IPSec MIB provides a generic mechanism for 300 performing packet processing based on a rule set. Rules within the 301 IPSec Configuration MIB are generic and simply bind a filter to an 302 action. Filters provided within the IPSec MIB itself are numerous and 303 fairly complete for most common packet filtering usage but externally 304 defined filters are supported. The actions encapsulated within the 305 IPSec MIB are mostly related to IKE and IPSec. 307 5.1.1. 308 IPSec Access Control 310 The PANA protocol authenticates the client and also establishes a 311 PANA security association between the PANA client and PANA 312 authentication agent at the end of successful authentication. The 313 PANA authentication agent (PAA) indicates the results of the 314 authentication using the PANA-Bind-Request message wherein it can 315 indicate the access control method enforced by the access network and 316 the IP address of the corresponding EP. 318 When IPSec is used to perform access control, the PANA protocol 319 [PANA] does not discuss any details of IPsec [IPSEC] SA 320 establishment. Indeed, [PANA-IPSEC] discusses the details for 321 establishing an IPsec security association between the PaC and the 322 EP. When the IPsec SA is successfully established, it can be used to 323 enforce access control and specifically used to prevent the service 324 theft mentioned in [PANA-THREATS]. 326 In this particular context, one assumes that the following have 327 already happened before the IPSec SA is established: 329 1. PANA client (PaC) learns the IP address of the Enforcement Point 330 (EP) during the PANA exchange. 331 2. PaC learns that the network uses IPsec [IPSEC] for securing the 332 link between PaC and EP during the PANA exchange. 333 3. PaC has already acquired an IP address and EP knows about the IP 334 address of the PaC, before the IKE exchange starts. If IPv6 is 335 being used, the EP needs to know both the global address and the 336 link-local address of the PaC. 338 The PAA is responsible to communicate to EP the following before IKE 339 phase 1 exchange begins: 340 . the IKE pre-shared key, 341 . the IP address of the PaC, 342 . and the PANA session ID (for pre-shared key derivation). 344 When PAA and EP are not co-located, the PAA-2-EP protocol MUST carry 345 this information. SNMP, together with the IPSec Configuration MIB 346 enable such configurations without any modification. The whole 347 behaviour of the EP can be configured by provisioning the IPSec MIB 348 objects. 350 For example, the ipspIkeActionTable contains a list of the parameters 351 used for an IKE phase 1 SA negotiation. For further detail, please 352 refer directly to [IPSEC-MIB]. 354 5.1.2. 355 General Access Control 357 More generally, the PAA-2-EP protocol must carry DI-based filters in 358 order to control and police the network access of a PaC. According to 359 the definition of the Device Identifier in [PANA-REQ], such filters, 360 depending on the access technology, might contain any of IP address 361 or link-layer address of a connected device. 363 Do note also that keying material might be provisioned for the 364 particular case where access control is performed using IPSec ([PANA- 365 IPSEC], see the previous section 5.1.1). 367 For Ipv4/v6 address-based filters provisioning, the IPSec 368 configuration MIB [IPSEC-MIB] provides means to filter the traffic 369 based on the IP header information. IPSec MIB-defined 370 IpspIpHeaderFilter provides such facilities: one can define the 371 various tests that are used when evaluating a given IP packet. The 372 results of each test are ANDed together to produce the result of the 373 entire filter. When processing this filter, it is recommended for 374 efficiency reasons that the filter halt processing the instant any of 375 the specified tests fail. The various tests definable in this table 376 are as follows: 377 . Source Address 378 . Destination Address 379 . Source Port Range 380 . Destination Port Range 381 . Protocol 382 . ipv6 Flow Label (Ipv6 only) 384 For Layer 2 address-based classification, additional filters might be 385 designed if needed. Section 6 gives an example of the definition of a 386 new IEEE 802-based filter, which may be useful in appropriate access 387 networks. 389 IPSec Compound filter and action sequences can be defined for 390 administrators that need more complex or need to chain multiple 391 actions together based on success/failure states. The compound 392 mechanisms are also generic and let PANA-specific MIB elements to be 393 used within the compound bindings. 395 5.1.3. 396 New PaC Notification 398 The IPSec MIB provides a means to notify to the SNMP manager (PAA) 399 information on packets matching/not matching the filters of given 400 rule. Such notification mechanisms and objects can be re-used for 401 notifying the PAA that unauthorized packets are trying to pass 402 through the EP. 404 Section 6 defines a new SNMP notification, which aims at satisfying 405 this requirement. It re-uses existing notification variable objects 406 pre-defined in the IPSec MIB. 408 This "New PaC Notification" (panaNewPacNotification) is triggered by 409 the detection by the EP of traffic coming from an unauthorized 410 source. The objects sent must include the ipspIPSourceType, 411 ipspIPSourceAddress, ipspIPDestinationType, and 412 ipspIPDestinationAddress objects to indicate the packet source and 413 destination of the packet that triggered the action. Additionally, 414 the ipspIPInterfaceType, ipspIPInterfaceAddress, and 415 ipspPacketDirection objects are included to indicate which interface 416 the action was executed in association with and if the packet was 417 inbound or outbond through the endpoint. See [IPSEC-MIB] for further 418 details. 420 Such a notification is able to trigger the sending of PANA-Start- 421 Request message from the PAA to newly identified PaC. 423 5.2. Differentiated Services MIB 425 The DiffServ MIB [DS-MIB] is a very powerful and flexible MIB module, 426 however, this flexibility may be too broad in general for the PANA 427 specific needs. 429 However, the DiffServ model of using different tables for data path 430 elements could be useful for EP configuration. The DiffServ MIB 431 module connects datapath building blocks (classifiers, meters, static 432 actions, etc.) together. 434 The use of RowPointers as connectors in the DiffServ MIB allows for 435 the simple extension of the MIB. The RowPointers, whether "next" or 436 "specific", may point to Entries defined in other MIB modules. This 437 mechanism can point to other, possibly vendor-specific, configuration 438 MIB modules. 440 The Diffserv MIB natively provides IP Header-based filters and 441 Drop/Accept basic actions. It can be sufficient in many situations. 443 Anyway, the remaining of the document does not further study the 444 DiffServ MIB module applicability to PANA. 446 6. PANA extension to the IPSec MIB 448 Many existing IPSec MIB objects defined in the IPSec Configuration 449 MIB modules can be efficiently re-used for the PANA-specific needs. 450 This is detailed in section 5.1. 452 The following sections define additional PANA-specific objects that 453 extend the IPSec MIB module in order to entirely satisfy the PAA-2-EP 454 interface requirements. 456 6.1. PANA MIB Overview 458 . 802 filters 459 . New PaC Notification 461 6.2. PANA-specific objects definition 463 PANA-MIB DEFINITIONS ::= BEGIN 465 IMPORTS 467 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE 468 FROM SNMPv2-SMI 470 RowStatus, PhysAddress 471 FROM SNMPv2-TC 473 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 474 FROM SNMPv2-CONF 476 IpspMib, ipspActionExecuted, ipspIPInterfaceType, 477 ipspIPInterfaceAddress, ipspIPSourceType, ipspIPSourceAddress, 478 ipspIPDestinationType, ipspIPDestinationAddress, ipspPacketDirection 479 FROM IPSEC-POLICY-MIB; 481 -- 482 -- Module identity 483 -- 485 panaMIB MODULE-IDENTITY 486 LAST-UPDATED 487 "200210310000Z" -- 31 October 2003 488 ORGANIZATION 489 "IETF PANA Working Group" 490 CONTACT-INFO 491 "Yacine El Mghazli 492 Alcatel 493 91460 Marcoussis, France 494 Phone: +33 1 69 63 41 87 495 Email: yacine.el_mghazli@alcatel.fr" 496 DESCRIPTION 497 "The MIB module for defining additional PANA-specific objects to 498 the IPSec Configuration MIB. Copyright (C) The Internet Society 499 (2003). This version of this MIB module is part of RFC XXXX, see 500 the RFC itself for full legal notices." 502 -- Revision History 503 REVISION 504 "200210310000Z" -- 31 October 2003 505 DESCRIPTION 506 "Initial version, published as draft-yacine-pana- 507 paa2ep-snmp-00.txt" 508 ::= { ipspMib XXX } -- XXX to be assigned by IANA 510 -- 511 -- groups of related objects 512 -- 514 panaConfigObjects OBJECT IDENTIFIER 515 ::= { panaMIB 1 } 516 panaNotificationObjects OBJECT IDENTIFIER 517 ::= { panaMIB 2 } 518 panaConformanceObjects OBJECT IDENTIFIER 519 ::= { panaMIB 3 } 521 -- 522 -- Textual Conventions 523 -- 525 -- TBD. 527 -- 528 -- PANA Additional Filters Objects 529 -- 531 -- 532 -- The IEEE 802 Filter Table 533 -- 535 pana802FilterTable OBJECT-TYPE 536 SYNTAX SEQUENCE OF Pana802FilterEntry 537 MAX-ACCESS not-accessible 538 STATUS current 539 DESCRIPTION 540 " IEEE 802-based filter definitions. A class that contains 541 attributes of IEEE 802 (e.g., 802.3) traffic that form 542 filters that are used to perform traffic classification." 543 ::= { panaConfigObjects 1 } 545 pana802FilterEntry OBJECT-TYPE 546 SYNTAX Pana802FilterEntry 547 MAX-ACCESS not-accessible 548 STATUS current 549 DESCRIPTION 550 " IEEE 802-based filter definitions. An entry specifies 551 (potentially) several distinct matching components. Each 552 component is tested against the data in a frame 553 individually. An overall match occurs when all of the 554 individual components match the data they are compared 555 against in the frame being processed. A failure of any 556 one test causes the overall match to fail. 557 Wildcards may be specified for those fields that are not 558 relevant." 559 INDEX { pana802FilterName } 560 ::= { pana802FilterTable 1 } 562 Pana802FilterEntry ::= SEQUENCE { 563 pana802FilterName SnmpAdminString, 564 pana802FilterType BITS, 565 pana802FilterDstAddr PhysAddress, 566 pana802FilterDstAddrMask PhysAddress, 567 pana802FilterSrcAddr PhysAddress, 568 pana802FilterSrcAddrMask PhysAddress, 569 pana802FilterVlanId Integer32, 570 pana802FilterVlanTagRequired INTEGER, 571 pana802FilterEtherType Integer32, 572 pana802FilterUserPriority BITS, 573 pana802FiltLastChanged TimeStamp, 574 pana802FiltStorageType StorageType, 575 pana802FiltRowStatus RowStatus 577 } 579 pana802FilterNamer OBJECT-TYPE 580 SYNTAX SnmpAdminString (SIZE(1..32)) 581 MAX-ACCESS not-accessible 582 STATUS current 583 DESCRIPTION 584 "The administrative name for this filter. " 585 := { pana802FilterEntry 1 } 587 pana802FilterType OBJECT-TYPE 588 SYNTAX BITS { srcAddress(0), 589 dstAddress(1), 590 vlanId(4), 591 etherType(5), 592 userPriority(6) } 593 MAX-ACCESS read-create 594 STATUS current 595 DESCRIPTION 596 "This defines the various tests that are used when evaluating 597 a given filter. The results of each test are ANDed together 598 to produce the result of the entire filter. When processing 599 this filter, it is recommended for efficiency reasons that 600 the filter halt processing the instant any of the specified 601 tests fail. 603 Once a row is 'active', this object's value may not be 604 changed unless all the appropriate columns needed by the new 605 value to be imposed on this object have been appropriately 606 configured. . " 607 := { pana802FilterEntry 2 } 609 pana802FilterDstAddr OBJECT-TYPE 610 SYNTAX PhysAddress 611 MAX-ACCESS read-create 612 STATUS current 613 DESCRIPTION 614 "The 802 address against which the 802 DA of incoming 615 traffic streams will be compared. Frames whose 802 DA 616 matches the physical address specified by this object, 617 taking into account address wildcarding as specified by the 618 pana802FilterDstAddrMask object, are potentially subject to 619 the processing guidelines that are associated with this 620 entry through the related action class." 621 := { pana802FilterEntry 3 } 623 pana802FilterDstAddrMask OBJECT-TYPE 624 SYNTAX PhysAddress 625 MAX-ACCESS read-create 626 STATUS current 627 DESCRIPTION 628 "This object specifies the bits in a 802 destination address 629 that should be considered when performing a 802 DA 630 comparison against the address specified in the 631 pana802FilterDstAddr object. 632 The value of this object represents a mask that is logically 633 and'ed with the 802 DA in received frames to derive the 634 value to be compared against the pana802FilterDstAddr 635 address. A zero bit in the mask thus means that the 636 corresponding bit in the address always matches. The 637 pana802FilterDstAddr value must also be masked using this 638 value prior to any comparisons. 639 The length of this object in octets must equal the length in 640 octets of the pana802FilterDstAddr. Note that a mask with no 641 bits set (i.e., all zeroes) effectively wildcards the 642 pana802FilterDstAddr object." 644 ::= { pana802FilterEntry 4 } 646 pana802FilterSrcAddr OBJECT-TYPE 647 SYNTAX PhysAddress 648 MAX-ACCESS read-create 649 STATUS current 650 DESCRIPTION 651 "The 802 MAC address against which the 802 MAC SA of 652 incoming traffic streams will be compared. Frames whose 802 653 MAC SA matches the physical address specified by this 654 object, taking into account address wildcarding as specified 655 by the pana802FilterSrcAddrMask object, are potentially 656 subject to the processing guidelines that are associated 657 with this entry through the related action class." 658 ::= { pana802FilterEntry 5 } 660 pana802FilterSrcAddrMask OBJECT-TYPE 661 SYNTAX PhysAddress 662 MAX-ACCESS read-create 663 STATUS current 664 DESCRIPTION 665 "This object specifies the bits in a 802 MAC source address 666 that should be considered when performing a 802 MAC SA 667 comparison against the address specified in the 668 pana802FilterSrcAddr object. 669 The value of this object represents a mask that is logically 670 and'ed with the 802 MAC SA in received frames to derive the 671 value to be compared against the pana802FilterSrcAddr 672 address. A zero bit in the mask thus means that the 673 corresponding bit in the address always matches. The 674 pana802FilterSrcAddr value must also be masked using this 675 value prior to any comparisons. 676 The length of this object in octets must equal the length in 677 octets of the pana802FilterSrcAddr. Note that a mask with no 678 bits set (i.e., all zeroes) effectively wildcards the 679 pana802FilterSrcAddr object." 680 ::= { pana802FilterEntry 6 } 682 pana802FilterVlanId OBJECT-TYPE 683 SYNTAX Integer32 (-1 | 1..4094) 684 MAX-ACCESS read-create 685 STATUS current 686 DESCRIPTION 687 "The VLAN ID (VID) that uniquely identifies a VLAN 688 within the device. This VLAN may be known or unknown 689 (i.e., traffic associated with this VID has not yet 690 been seen by the device) at the time this entry 691 is instantiated. 692 Setting the pana802FilterVlanId object to -1 indicates that 693 VLAN data should not be considered during traffic 694 classification." 695 ::= { pana802FilterEntry 7 } 697 pana802FilterVlanTagRequired OBJECT-TYPE 698 SYNTAX INTEGER { 699 taggedOnly(1), 700 priorityTaggedPlus(2), 701 untaggedOnly(3), 702 ignoreTag(4) 703 } 704 MAX-ACCESS read-create 705 STATUS current 706 DESCRIPTION 707 "This object indicates whether the presence of an 708 IEEE 802.1Q VLAN tag in data link layer frames must 709 be considered when determining if a given frame 710 matches this 802 filter entry. 711 A value of 'taggedOnly(1)' means that only frames 712 containing a VLAN tag with a non-Null VID (i.e., a 713 VID in the range 1..4094) will be considered a match. 714 A value of 'priorityTaggedPlus(2)' means that only 715 frames containing a VLAN tag, regardless of the value 716 of the VID, will be considered a match. 717 A value of 'untaggedOnly(3)' indicates that only 718 untagged frames will match this filter component. 719 The presence of a VLAN tag is not taken into 720 consideration in terms of a match if the value is 721 'ignoreTag(4)'." 722 ::= { pana802FilterEntry 8 } 724 pana802FilterEtherType OBJECT-TYPE 725 SYNTAX Integer32 (-1 | 0..'ffff'h) 726 MAX-ACCESS read-create 727 STATUS current 728 DESCRIPTION 729 "This object specifies the value that will be compared 730 against the value contained in the EtherType field of an 731 IEEE 802 frame. Example settings would include 'IP' 732 (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137). 733 Setting the pana802FilterEtherTypeMin object to -1 indicates 734 that EtherType data should not be considered during traffic 735 classification. 736 Note that the position of the EtherType field depends on 737 the underlying frame format. For Ethernet-II encapsulation, 738 the EtherType field follows the 802 MAC source address. For 739 802.2 LLC/SNAP encapsulation, the EtherType value follows 740 the Organization Code field in the 802.2 SNAP header. The 741 value that is tested with regard to this filter component 742 therefore depends on the data link layer frame format being 743 used. If this 802 filter component is active when there is 744 no EtherType field in a frame (e.g., 802.2 LLC), a match is 745 implied." 746 ::= { pana802FilterEntry 9 } 748 pana802FilterUserPriority OBJECT-TYPE 749 SYNTAX BITS { 750 matchPriority0(0), 751 matchPriority1(1), 752 matchPriority2(2), 753 matchPriority3(3), 754 matchPriority4(4), 755 matchPriority5(5), 756 matchPriority6(6), 757 matchPriority7(7) 758 } 759 MAX-ACCESS read-create 760 STATUS current 761 DESCRIPTION 762 "The set of values, representing the potential range 763 of user priority values, against which the value contained 764 in the user priority field of a tagged 802.1 frame is 765 compared. A test for equality is performed when determining 766 if a match exists between the data in a data link layer 767 frame and the value of this 802 filter component. Multiple 768 values may be set at one time such that potentially several 769 different user priority values may match this 802 filter 770 component. 771 Setting all of the bits that are associated with this 772 object causes all user priority values to match this 773 attribute. This essentially makes any comparisons 774 with regard to user priority values unnecessary. Untagged 775 frames are treated as an implicit match." 776 ::= { pana802FilterEntry 10 } 778 pana802FiltLastChanged OBJECT-TYPE 779 SYNTAX TimeStamp 780 MAX-ACCESS read-only 781 STATUS current 782 DESCRIPTION 783 "The value of sysUpTime when this row was last modified or 784 created either through SNMP SETs or by some other external 785 means." 786 ::= { pana802FilterEntry 11 } 788 pana802FiltStorageType OBJECT-TYPE 789 SYNTAX StorageType 790 MAX-ACCESS read-create 791 STATUS current 792 DESCRIPTION 793 "The storage type for this row. Rows in this table which were 794 created through an external process may have a storage type 795 of readOnly or permanent." 796 DEFVAL { nonVolatile } 797 ::= { pana802FilterEntry 12 } 799 pana802FiltRowStatus OBJECT-TYPE 800 SYNTAX RowStatus 801 MAX-ACCESS read-create 802 STATUS current 803 DESCRIPTION 804 "This object indicates the conceptual status of this row. 805 This object may not be set to active if the requirements of 806 the pana802FilterType object are not met. In other words, 807 if the associated value columns needed by a particular test 808 have not been set, then attempting to change this row to an 809 active state will result in an inconsistentValue error. See 810 the pana802FilterType object description for further 811 details." 812 ::= { pana802FilterEntry 13 } 814 -- 815 -- 816 -- Notification objects information 817 -- 818 -- 820 panaNotifications OBJECT IDENTIFIER ::= 821 { panaNotificationObjects 0 } 823 panaNewPacNotification NOTIFICATION-TYPE 824 OBJECTS { ipspActionExecuted, ipspIPInterfaceType, 825 ipspIPInterfaceAddress, 826 ipspIPSourceType, ipspIPSourceAddress, 827 ipspIPDestinationType, 828 ipspIPDestinationAddress, 829 ipspPacketDirection } 830 STATUS current 831 DESCRIPTION 832 "Notification that AP detected traffic coming from an 833 unauthorized source. The objects sent must include the 834 ipspActionExecuted which will indicate which action was executed 835 within the scope of the rule. Additionally, the ipspIPSourceType, 836 ipspIPSourceAddress, ipspIPDestinationType, and 837 ipspIPDestinationAddress, objects must be included to indicate the 838 packet source and destination of the packet that triggered the 839 action. The ipspIPInterfaceType, ipspIPInterfaceAddress, and 840 ipspPacketDirection objects are included to indicate which endpoint 841 the packet was associated with." 842 ::= { panaNotifications 1 } 844 -- 845 -- 846 -- Conformance information 847 -- 848 -- 850 -- TBD. 852 END 854 7. Security Considerations 856 -- if you have any read-write and/or read-create objects, please 857 -- describe their specific sensitivity or vulnerability. 858 -- RFC 2669 has a very good example. 860 There are a number of management objects defined in this MIB module 861 with a MAX-ACCESS clause of read-write and/or read-create. Such 862 objects may be considered sensitive or vulnerable in some network 863 environments. The support for SET operations in a non-secure 864 environment without proper protection can have a negative effect on 865 network operations. These are the tables and objects and their 866 sensitivity/vulnerability: 868 870 -- else if there are no read-write objects in your MIB module 872 There are no management objects defined in this MIB module that have 873 a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB 874 module is implemented correctly, then there is no risk that an 875 intruder can alter or create any management objects of this MIB 876 module via direct SNMP SET operations. 878 -- for all MIB modules you must evaluate whether any readable objects 879 -- are sensitive or vulnerable (for instance, if they might reveal 880 -- customer information or violate personal privacy laws such as 881 -- those of the European Union if exposed to unathorized parties) 883 Some of the readable objects in this MIB module (i.e., objects with a 884 MAX-ACCESS other than not-accessible) may be considered sensitive or 885 vulnerable in some network environments. It is thus important to 886 control even GET and/or NOTIFY access to these objects and possibly 887 to even encrypt the values of these objects when sending them over 888 the network via SNMP. These are the tables and objects and their 889 sensitivity/vulnerability: 891 892 SNMP versions prior to SNMPv3 did not include adequate security. Even 893 if the network itself is secure (for example by using IPSec), even 894 then, there is no control as to who on the secure network is allowed 895 to access and GET/SET (read/change/create/delete) the objects in this 896 MIB module. 898 It is RECOMMENDED that implementers consider the security features as 899 provided by the SNMPv3 framework (see [SNMP-FRWK], section 8), 900 including full support for the SNMPv3 cryptographic mechanisms (for 901 authentication and privacy). 903 Further, deployment of SNMP versions prior to SNMPv3 is NOT 904 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 905 enable cryptographic security. It is then a customer/operator 906 responsibility to ensure that the SNMP entity giving access to an 907 instance of this MIB module is properly configured to give access to 908 the objects only to those principals (users) that have legitimate 909 rights to indeed GET or SET (change/create/delete) them. 911 References 913 Normative References 915 [PANA] D. Forsberg, Y. Ohba, B. Pati, H. Tschofenig, A. Yegin, 916 "Protocol for Carrying Authentication for Network Access 917 (PANA)"(draft-ietf-pana-pana-02.txt). 919 [PANA-REQ] R. Penno, et al., "Protocol for Carrying Authentication 920 for Network Access (PANA) Requirements and Terminology" (draft- 921 ietf-pana-requirements-07.txt). 923 [PANA-IPSEC] Parthasarathy, M., "PANA enabling IPsec based Access 924 Control", draft-ietf-pana-ipsec-00 (work in progress), October 925 2003. 927 [PANA-THREATS] Parthasarathy, M., "PANA Threat Analysis and security 928 requirements", draft-ietf-pana-threats-eval-04 (work in progress), 929 May 2003. 931 [USM] Blumenthal, U. and B. Wijnen, "User-Based Security Model (USM) 932 for Version 3 of the Simple Network Management Protocol (SNMPv3)", 933 STD 62, RFC 3414, December 2002. 935 [IPSEC-MIB] Baer, M., Charlet, R., Hardaker, W., Story, R., Wang, C., 936 "IPsec Policy Configuration MIB module", draft-ietf-ipsp-ipsec- 937 conf-mib-06.txt, March, 2003. 939 [DS-MIB] Baker, F., Chan, K., Smith, A., "Management Information Base 940 for the Differentiated Services Architecture", RFC 3289, May 2002. 942 [IPSEC] Kent, S., and Atkinson, R., "Security Architecture for the 943 Internet Protocol", RFC 2401, November 1998. 945 [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", 946 RFC 2409, November 1998. 948 [STD] Bradner, S., "The Internet Standards Process -- Revision 3", 949 BCP 9, RFC 2026, October 1996. 951 [SNMP-FRWK] Case, J., Mundy, R., Partain, D. and B. Stewart, 952 "Introduction and Applicability Statements for Internet-Standard 953 Management Framework", RFC 3410, December 2002. 955 [SNMP-ARCH] Harrington, D., Presuhn, R. and B. Wijnen, "An 956 Architecture for Describing Simple Network Management Protocol 957 (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, March 1997. 962 [SMIv2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 963 Rose, M. and S. Waldbusser, "Structure of Management Information 964 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 966 [SMI-TC] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 967 Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 968 58, RFC 2579, April 1999. 970 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 971 Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", 972 STD 58, RFC 2580, April 1999. 974 Informative References 976 [PAA-EP-EVAL] Y. El Mghazli , "PANA PAA-EP Protocol Considerations" 977 (draft-yacine-pana-paa2ep-prot-eval-00.txt). 979 [PAA-EP-REQ] Y. El Mghazli , "PANA PAA-EP Protocol Requirements" 980 (draft-yacine-pana-paa-ep-reqs-00.txt). 982 Acknowledgements 984 This document leverages on similar works done in the MIDCOM working 985 group. Thanks to the authors of those IDs. 987 The author would like to thank Julien Bournelle for his grateful 988 help, comments and feedback during the edition of this document. 990 Author's Addresses 992 Yacine El Mghazli 993 Alcatel 994 Route de Nozay 995 91460 Marcoussis cedex 996 Phone: +33 (0)1 69 63 41 87 997 Email: yacine.el_mghazli@alcatel.fr 999 Full Copyright Statement 1001 "Copyright (C) The Internet Society (2003). All Rights Reserved. 1003 This document and translations of it may be copied and furnished to 1004 others, and derivative works that comment on or otherwise explain it 1005 or assist in its implementation may be prepared, copied, published 1006 and distributed, in whole or in part, without restriction of any 1007 kind, provided that the above copyright notice and this paragraph are 1008 included on all such copies and derivative works. However, this 1009 document itself may not be modified in any way, such as by removing 1010 the copyright notice or references to the Internet Society or other 1011 Internet organizations, except as needed for the purpose of 1012 developing Internet standards in which case the procedures for 1013 copyrights defined in the Internet Standards process must be 1014 followed, or as required to translate it into languages other than 1015 English. 1017 The limited permissions granted above are perpetual and will not be 1018 revoked by the Internet Society or its successors or assigns. 1020 This document and the information contained herein is provided on an 1021 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1022 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1023 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1024 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1025 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.