idnits 2.17.1 draft-ietf-pana-snmp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1808. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 655: '... acknowledged) MUST be used. Then t...' RFC 2119 keyword, line 677: '...cific parameters SHOULD be accessed vi...' RFC 2119 keyword, line 1604: '... and USM MUST be used with any v3...' RFC 2119 keyword, line 1626: '... It is RECOMMENDED that implementers...' RFC 2119 keyword, line 1632: '... RECOMMENDED. Instead, it is RECOMM...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 23, 2006) is 6516 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) == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-11 == Outdated reference: A later version (-07) exists of draft-ietf-ipsp-spd-mib-06 == Outdated reference: A later version (-02) exists of draft-ietf-ipsp-ikeaction-mib-01 == Outdated reference: A later version (-02) exists of draft-ietf-ipsp-ipsecaction-mib-01 == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-06 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-13 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group Y. El Mghazli 3 Internet-Draft Alcatel 4 Expires: December 25, 2006 Y. Ohba 5 Toshiba 6 J. Bournelle 7 GET/INT 8 June 23, 2006 10 SNMP usage for PAA-EP interface 11 draft-ietf-pana-snmp-06 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 25, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The PANA Authentication Agent (PAA) does not necessarily act as an 45 Enforcement Point (EP) to prevent unauthorized access or usage of the 46 network. When a PANA Client successfully authenticates itself to the 47 PAA, EP(s) (e.g., access routers) will need to be suitably notified. 48 The PANA working group recommends the use of Simple Network 49 Management Protocol Version 3 (SNMPv3) to deliver the authorization 50 information to one or more EPs when the PAA is separated from EPs. 52 The present document provides the necessary information and 53 extensions needed to use SNMPv3 as the PAA-EP protocol. 55 Table of Contents 57 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. PAA/EP separation context . . . . . . . . . . . . . . . . 5 60 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. The Internet-Standard Management Framework . . . . . . . . . . 7 62 4. SNMP Applicability with the PANA framework . . . . . . . . . . 8 63 4.1. SNMPv3 General applicability . . . . . . . . . . . . . . . 8 64 4.2. Compliancy of SNMP against the PANA requirements . . . . . 9 65 4.2.1. Authorization Consideration . . . . . . . . . . . . . 9 66 4.2.2. PAA-EP relation . . . . . . . . . . . . . . . . . . . 10 67 4.2.3. Secure Communication . . . . . . . . . . . . . . . . . 10 68 4.2.4. Notification of PaC presence . . . . . . . . . . . . . 10 69 4.2.5. Accounting Consideration . . . . . . . . . . . . . . . 11 70 4.2.6. Peer Liveness Test and Rebooted Peer Detection . . . . 11 71 5. Applicability of IPsec configuration MIBs . . . . . . . . . . 13 72 5.1. General IP Access Control . . . . . . . . . . . . . . . . 13 73 5.2. Network Layer Secure Access Control (IPsec) . . . . . . . 14 74 6. PANA extension to the IPsec SPD MIB . . . . . . . . . . . . . 17 75 6.1. Bootstrapping link layer ciphers . . . . . . . . . . . . . 17 76 6.2. Notification of PaC presence . . . . . . . . . . . . . . . 17 77 6.3. PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 18 78 6.4. PANA MIB Objects Definition . . . . . . . . . . . . . . . 19 79 7. Applicability of RTFM Meter MIB . . . . . . . . . . . . . . . 29 80 8. EP Configuration Example . . . . . . . . . . . . . . . . . . . 30 81 8.1. Common setup . . . . . . . . . . . . . . . . . . . . . . . 30 82 8.2. General IP-based Access Control . . . . . . . . . . . . . 32 83 8.3. IPsec-based Access Control . . . . . . . . . . . . . . . . 33 84 8.4. Link-layer Access control . . . . . . . . . . . . . . . . 37 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 44 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 92 Intellectual Property and Copyright Statements . . . . . . . . . . 47 94 1. Terminology and Definitions 96 PANA: Protocol for Carrying Authentication for Network Access. 98 PaC (PANA Client): 100 The client side of the protocol that resides in the host device, 101 which is responsible for providing the credentials to prove its 102 identity for network access authorization. A PaC is responsible 103 for requesting network access and engaging in authentication 104 process using the PANA protocol. 106 DI (Device Identifier): 108 The identifier used by the network as a handle to control and 109 police the network access of a client. Depending on the access 110 technology, this identifier might contain any of IP address, link- 111 layer address, switch port number, etc. of a connected device. 113 PAA (PANA Authentication Agent): 115 The access network (server) side entity of the PANA protocol. A 116 PAA is in charge of interfacing with the PaCs for authenticating 117 and authorizing them for the network access service. To this end, 118 the PAA verifies the credentials provided by a PANA client and 119 grants network access service to the device associated with the 120 client and identified by a DI. 122 The PAA is also responsible for updating the access control state 123 (i.e., filters) depending on the authorization. The PAA 124 communicates the updated state to the enforcement points in the 125 network. When the PAA and the EP are separated, a protocol is 126 required to carry the authorized client attributes from the PAA to 127 the EP. SNMPv3 is used to this end. 129 EP (Enforcement Point): 131 A node on the access network where per-packet enforcement policies 132 are applied on the inbound and outbound traffic of client devices. 133 The EP uses non-cryptographic or cryptographic filters to 134 selectively allow and discard data packets. These filters may be 135 applied at the link-layer or the IP-layer. An EP learns the 136 attributes of the authorized clients (DI and optionally 137 cryptographic keys) from the PAA. 139 Authentication Server (AS): 141 The server implementation that is in charge of verifying the 142 credentials of a PaC that is requesting the network access 143 service. The AS receives requests from the PAA on behalf of the 144 PaCs, and responds with the result of verification together with 145 the authorization parameters (e.g., allowed bandwidth, IP 146 configuration, etc). The AS might be hosted on the same node as 147 the PAA, on a dedicated node on the access network, or on a 148 central server somewhere in the Internet. 150 2. Introduction 152 2.1. PAA/EP separation context 154 PANA enables access control by identifying legitimate clients and 155 generating filtering information for access control mechanisms. 156 [I-D.ietf-pana-framework] defines a general AAA and access control 157 framework. The PANA protocol itself provides client authentication 158 and authorization functionality for securing network access. Access 159 control ensures that only authenticated and authorized clients can 160 gain access to the network. 162 Access control can be achieved by placing EPs (Enforcement Points) in 163 the network for policing the traffic flow. EPs should prevent data 164 traffic from and to any unauthorized client unless it's either PANA 165 or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor 166 discovery, DHCP, etc.). 168 Figure 1 below illustrates the functional entities and the interfaces 169 (protocols, APIs) among them. 171 RADIUS/ 172 Diameter/ 173 +-----+ PANA +-----+ LDAP/ API +-----+ 174 | PaC |<----------------->| PAA |<---------------->| AS | 175 +-----+ +-----+ +-----+ 176 ^ ^ 177 | | 178 | +-----+ | 179 IKE/ +-------->| EP |<--------+ SNMP/ API 180 4-way handshake +-----+ 182 Figure 1: PANA Functional Model 184 Some of the entities may be co-located depending on the deployment 185 scenario. 187 The EP on the access network allows general data traffic from any 188 authorized PaC, whereas it allows only limited type of traffic (e.g., 189 PANA, DHCP, router discovery) for the unauthorized PaCs. This 190 ensures that the newly attached clients have the minimum access 191 service to engage in PANA and get authorized for the unlimited 192 service. 194 If the PaC is authorized to gain the access to the network, the PAA 195 also sends the PaC-specific attributes (e.g., IP address, 196 cryptographic keys, etc.) to the EP by using SNMP. The EP uses this 197 information to enforce policy rules allowing data traffic from and to 198 the PaC to pass through. 200 In case a cryptographic access control needs to be enabled after the 201 PANA authentication, a secure association protocol runs between the 202 PaC and the EP. The PaC should already have the input parameters to 203 this process as a result of the successful PANA exchange. Similarly, 204 the EP should have obtained them from the PAA via SNMP. Secure 205 association exchange produces the required security associations 206 between the PaC and the EP to enable per-packet protection. 208 Finally data traffic can start flowing from and to the newly 209 authorized PaC. 211 In this document, it is assumed that PAA and EP are pre-configured to 212 be able to communicate each other with a required security 213 association. In case where dynamic discovery is needed for PAA and 214 EP to know each other's address, then SNMPv3 engine-id discovery 215 could be used. Such dynamic discovery is out of scope of this 216 document. 218 2.2. Scope 220 Section 3 gives references for the SNMP framework. 222 Section 4 provides a general statement with regards to the 223 applicability of SNMP as the PAA-EP protocol. 225 IPsec configuration MIB modules were found to have general 226 applicability and varying levels of re-usability for PANA EP 227 authorization configuration using SNMP. Section 5 details the 228 applicability of this MIB set to the EP configuration and Section 6 229 defines some additional PANA-specific objects that extend the IPsec 230 SPD-MIB module [I-D.ietf-ipsp-spd-mib] in order to entirely satisfy 231 the PAA-EP interface requirements. 233 In the same manner, RTFM Meter MIB module was found to have general 234 applicability of re-usability for PANA EP accounting configuration 235 using SNMP. Section 7 details the applicability of this MIB to the 236 EP configuration. 238 Finally, Section 9 addresses the security considerations. 240 3. The Internet-Standard Management Framework 242 For a detailed overview of the documents that describe the current 243 Internet-Standard Management Framework, please refer to section 7 of 244 [RFC3410]. 246 Managed objects are accessed via a virtual information store, termed 247 the Management Information Base or MIB. MIB objects are generally 248 accessed through the Simple Network Management Protocol (SNMP). 249 Objects in the MIB are defined using the mechanisms defined in the 250 Structure of Management Information (SMI). This memo specifies a MIB 251 module that is compliant to the SMIv2, which is described in STD 58 252 [RFC2578], STD 58 [RFC2579] and STD 58 [RFC2580]. 254 4. SNMP Applicability with the PANA framework 256 This section provides a general statement with regards to the 257 applicability of SNMP as the PAA-EP protocol. This analysis of SNMP 258 is specific to SNMPv3, which provides the security required for PANA 259 usage. SNMPv1 and SNMPv2c would be inappropriate for PANA since they 260 have been declared Historic, and because their messages have only 261 trivial security. 263 4.1. SNMPv3 General applicability 265 SNMPv3 is that it is a mature, well understood protocol, currently 266 deployed in various scenarios, with mature toolsets available for 267 SNMP managers and agents. 269 Application intelligence is captured in MIB modules, rather than in 270 the messaging protocol. MIB modules define a data model of the 271 information that can be collected and configured for a managed 272 functionality. The SNMP messaging protocol transports the data in a 273 standardized format without needing to understand the semantics of 274 the data being transferred. The endpoints of the communication 275 understand the semantics of the data. 277 Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly 278 due to variations in configuration requirements across vendors, few 279 MIB modules have been developed that enable standardized 280 configuration of managed devices across vendors. Since monitoring 281 can be done using only a least-common-denominator subset of 282 information across vendors, many MIB modules have been developed to 283 provide standardized monitoring of managed devices. As a result, 284 SNMP has been used primarily for monitoring rather than for 285 configuring network nodes. 287 SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c 288 versions. Specifically, SNMPv3 shares the separation of data 289 modeling (MIBs) from the protocol to transfer data, so all existing 290 MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, 291 and it shares operations and transport with SNMPv2c. The major 292 difference between SNMPv3 and earlier versions is the addition of 293 strong message security and controlled access to data. 295 SNMPv3 uses the architecture detailed in [RFC3411], where all SNMP 296 entities are capable of performing certain functions, such as the 297 generation of requests, response to requests, the generation of 298 asynchronous notifications, the receipt of notifications, and the 299 proxy-forwarding of SNMP messages. SNMP is used to read and 300 manipulate virtual databases of managed-application-specific 301 operational parameters and statistics, which are defined in MIB 302 modules. 304 4.2. Compliancy of SNMP against the PANA requirements 306 The following sections detail how the PAA-EP protocol requirements 307 are fully supported by SNMP: 309 4.2.1. Authorization Consideration 311 This section discusses PAA-EP communication in terms of authorization 312 aspects. 314 Binary Authorization: 316 Filtering rules to be installed on EP generally include a device 317 identifier of PaC, and also some cryptographic keying materials 318 (e.g., IKE [RFC2409] pre-shared key ) when cryptographic data 319 traffic protection is needed. Each keying material is uniquely 320 identified with a keying material name (e.g., ID_KEY_ID in IKE) 321 and has a lifetime for key management, accounting, access control 322 and security reasons in general. 324 PANA authorization management can be modeled in a way that is 325 consistent with existing standard MIB modules, this is detailed in 326 Section 5. Additional PANA-specific objects may be needed and are 327 defined in Section 6. 329 Profile-based authorization: 331 In addition to the device identifier and keying material, the PAA 332 may provide the EP with additional authorization information. For 333 instance, a user may be authorized to access the network within a 334 given class of service or for a maximum amount of units. The type 335 of units can be time (e.g., authorization lifetime), volume (e.g., 336 the number of incoming and/or outgoing packets and/or bytes), 337 service specific or money depending on the type of service event 338 [I-D.ietf-aaa-diameter-cc]. 340 This type of authorization might also require that the 341 communicating pair of PAA and EP to detect a dead or rebooted peer 342 in order to avoid possible inaccurate accounting. This aspect is 343 discussed in Section 4.2.6. 345 In any case, even if it is very likely to occur between the PAA 346 and EP, this kind of profile-based authorization is beyond the 347 scope of the PANA working group. Hence, the specification of the 348 MIB modules (existing or not) necessary to provide such policy 349 information is outside the scope of the present document, which 350 deals only with the so-called binary authorization. 352 4.2.2. PAA-EP relation 354 A number of deployment options are envisaged within the PANA 355 framework. See [I-D.ietf-pana-framework] for further details. 357 The SNMP framework [RFC3410] supports one-to-many, many-to-one, and 358 many-to-many relationships between the SNMP managers (PAAs) and 359 agents (EPs). 361 4.2.3. Secure Communication 363 SNMPv3 includes the User-based Security Model (USM, [RFC3414]), which 364 provides authentication, confidentiality, and integrity. 366 Additionally, USM has specific built-in mechanisms for preventing 367 replay attacks including unique protocol engine IDs, timers and 368 counters per engine and time windows for the validity of messages. 370 See [RFC3410] for the security features provided by the SNMPv3 371 framework. 373 4.2.4. Notification of PaC presence 375 The PaC may also choose to start sending packets before getting 376 authenticated. In that case, the network should detect this and the 377 PAA must send an unsolicited PANA-Start-Request message to the PaC. 378 The EP is the node that can detect such activity. In case they are 379 separate, there needs to be an explicit message to prompt the PAA. 381 Such a presence notification is done by using the SNMP notification 382 operation. See Section 6 and Section 6.2 for details on how new and 383 existing SNMP objects provide this feature. 385 The presence notification may contain both an IP address and a link- 386 layer address, or only one of them. 388 A presence notification without containing a link-layer address may 389 be generated where access control is performed using IPsec [I-D.ietf- 390 pana-ipsec]. 392 A presence notification without containing an IP address may be 393 generated when a link-layer frame that does not contain an IP address 394 is used as the notification trigger. If the PAA that received such a 395 notification from the EP has already a PANA session associated with 396 the link-layer address, it may use the notification as a trigger to 397 install filtering information to the EP. This can happen if the PaC 398 is roaming from one EP to another under the same PAA. 400 4.2.5. Accounting Consideration 402 Since authentication and authorization are closely related to 403 accounting in many cases, accounting aspects need to be considered in 404 the PAA-EP protocol. 406 The PAA device acts as an accounting client of a AAA protocol. The 407 PAA collects accounting information from the EP(s) it controls, and 408 sends the gathered data to the accounting server by using the AAA 409 protocol. 411 PANA accounting management can be done using RTFM (Real-Time Flow 412 Measurement) standard MIB module [RFC2720], this is detailed in 413 Section 7. 415 The authentication/authorization session identifier of a AAA protocol 416 is used by the accounting server to associate accounting information 417 with a particular authentication/authorization session to calculate 418 bills. The authentication/authorization session identifier may or 419 may not be the same as the PANA session identifier and it is the 420 responsibility of the PAA to organize the correlation between the 421 meters/filters at the EP and the PANA/AAA sessions at the PAA. 423 The communicating pair of the PAA and the EP might need to detect a 424 rebooted peer to avoid possible inaccurate accounting. This aspect 425 is discussed in Section 4.2.6. 427 4.2.6. Peer Liveness Test and Rebooted Peer Detection 429 PAA-EP protocol implementations need to be stateful, when considering 430 the authorization and accounting aspects as described in the previous 431 sections. The stateful nature provides the functionality to detect a 432 dead or rebooted peer in a timely fashion. On the other hand, this 433 does not mean that the PAA-EP protocol itself needs to be stateful. 434 For example, an SNMP entity (i.e., an SNMP engine plus SNMP 435 applications) can generate SNMP queries on a particular MIB at an 436 interval short enough to perform peer liveness test and rebooted peer 437 detection. 439 Also, the peer liveness test and rebooted peer detection need to be 440 performed securely. 442 When SNMPv3 is used as the PAA-EP protocol, the SNMP management 443 framework supports snmpEngineBoots MIB [RFC3411]. By periodically 444 sending SNMP query to the peer to check the current value of this MIB 445 with the use of SNMP Security Subsystem, it is possible for an SNMP 446 entity to securely perform peer liveness test and rebooted peer 447 detection between PAA and EP. 449 5. Applicability of IPsec configuration MIBs 451 This section details the applicability of existing IPsec 452 configuration MIB modules to the EP configuration. These were found 453 to have general applicability and a fair level of re-usability for 454 the PANA EP configuration: 456 IPSec Security Policy Database (SPD) Configuration MIB: 458 [I-D.ietf-ipsp-spd-mib] defines a MIB module (IPSEC-SPD-MIB) for 459 configuration of an IPSec Security Policy Database (SPD). No 460 IPsec or IKE specific actions are defined within this document. 462 IPsec Security Policy IKE Action MIB: 464 [I-D.ietf-ipsp-ikeaction-mib] defines a MIB module (IPSEC- 465 IKEACTION-MIB) for configuration of an IKE action within the IPsec 466 SPD. 468 IPsec Security Policy IPsec Action MIB: 470 [I-D.ietf-ipsp-ipsecaction-mib] defines a MIB module (IPSEC- 471 IPSECACTION-MIB) for configuring IPsec actions within the IPsec 472 SPD. 474 The EP enforces binary authorization by filtering data traffic on the 475 basis of the Device Identifier (DI) of the PaC. The PAA must 476 provision its EPs with DI-based filters in order to control and 477 police the network access of a PaC. According to the definition of 478 the Device Identifier in [RFC4058], such filters - depending on the 479 access technology - might be either a IPv4/6 address or a link-layer 480 address of a connected device. 482 Do note also that a keying material might be provisioned. The 483 particular case where access control is performed using IPsec is 484 specified in [I-D.ietf-pana-ipsec]. The configuration aspects in 485 this case are detailed in Section 5.2. 487 5.1. General IP Access Control 489 The IPsec SPD MIB module (SPD-MIB) is designed to configure an IPsec 490 security policy database in a policy and rule oriented fashion. This 491 module is divided into 3 portions (Rules, Filters, Actions). 492 Specifically, SPD-MIB provides a generic mechanism for performing 493 packet processing based on a rule set. 495 The policy-based packet filtering and the corresponding execution of 496 actions is of a more general nature than for IPsec configuration 497 only, such as for configuration of a firewall. Rules within the 498 IPsec SPD-MIB are generic and simply bind a filter to an action. 499 Filters provided within the SPD-MIB itself are numerous and fairly 500 complete for most common packet filtering usage but externally 501 defined filters are supported. 503 For IPv4/v6 address-based filters provisioning, the DIFFSERV-MIB 504 module defined in [RFC3289] provides means to filter the traffic 505 based on the IP header information. DiffServ Multi-field Classifier 506 table provides such facilities: one can define the various tests that 507 are used when evaluating a given IP packet. The various tests 508 definable in this table are as follows: 510 o IP source address prefix, including host, CIDR Prefix, and "any 511 source address" 513 o IP destination address prefix, including host, CIDR Prefix, and 514 "any destination address" 516 o IPv6 Flow ID 518 o IP protocol or "any" 520 o TCP/UDP/SCTP source port range, including "any" 522 o TCP/UDP/SCTP destination port range, including "any" 524 o Differentiated Services Code Point 526 The results of each test are ANDed together to produce the result of 527 the entire filter. 529 The actions encapsulated within the SPD-MIB module are basic drop/ 530 accept actions. These are sufficient to perform EP binary 531 authorization enforcement at the EP. 533 When profile-based authorization information is provided to the EP, 534 more advanced actions like classifiers, meters and schedulers might 535 be configured by the PAA. This is out of the scope of the present 536 document. 538 5.2. Network Layer Secure Access Control (IPsec) 540 The PANA protocol authenticates the client and also establishes a 541 PANA security association between the PANA client and PANA 542 authentication agent at the end of successful authentication. The 543 PAA indicates the results of the authentication using the PANA-Bind- 544 Request (PBR) message wherein it can indicate the access control 545 method enforced by the access network and the IP address of the 546 corresponding EP. 548 When IPsec is used to perform access control, the PANA protocol 549 [I-D.ietf-pana-pana] does not discuss any details of IPsec [RFC2401] 550 SA establishment. Indeed, [I-D.ietf-pana-ipsec] discusses the 551 details for establishing IPsec security associations between the PaC 552 and the EP. When the IPsec SAs are successfully established, it can 553 be used to enforce access control and specifically used to prevent 554 the service theft mentioned in [RFC4016]. 556 In this particular context, one assumes that the following have 557 already happened before the IPsec SAs are established: 559 1. PANA client (PaC) and PAA mutually authenticate each other using 560 EAP methods that derive the AAA-Key [I-D.ietf-eap-keying]. 562 2. PaC learns the IP address of the Enforcement point (EP) during 563 the PANA exchange. 565 3. PaC learns that the network uses IPsec [RFC2401] for securing the 566 link between PaC and EP during the PANA exchange (PBR message). 568 4. PaC configures an IP address address before the PANA protocol 569 begins (the pre-PANA Address (PRPA), see [I-D.ietf-pana-pana]). 571 The IPsec IKE Action MIB module (IKEACTION-MIB) works within the 572 framework of the IPsec SPD-MIB. It can be referenced as an action by 573 the SPD-MIB and is used to configure IKE negotiations between network 574 devices. Hence, together with the SPD-MIB, the IKEACTION-MIB module 575 enables the PAA to configure IPSEC-based access control at the EP. 577 The PAA is then responsible to communicate to EP the following 578 information before IKE phase 1 exchange begins between PaC and EP: 580 The IKE pre-shared key: 582 To this end, the PAA must set a row in the IKE Credential Filter 583 table of the IKEACTION-MIB. This table defines filters, which can 584 be used to match credentials of IKE peers, where the credentials 585 in question have been obtained from an IKE phase 1 exchange. They 586 may be X.509 certificates, Kerberos tickets, or Pre-shared keys, 587 etc. 589 The PRPA of the PaC: 591 The DiffServ Multi-Field Classifier of the DIFFSERV-MIB is used 592 for configuring the SPD in a similar manner than what is described 593 in Section 5.1. 595 The Key-Id and PANA session ID: 597 [I-D.ietf-pana-ipsec] states that PaC and EP should use the PANA 598 session ID concatenated with the AAA-key as the value of the 599 ID_KEY_ID in aggressive mode for establishing the phase 1 SA. 600 Section 8 details usage examples that illustrate the way the 601 IKEACTION-MIB is used for this purpose. 603 6. PANA extension to the IPsec SPD MIB 605 Many existing MIB objects defined in the IPsec Configuration MIB 606 modules can be efficiently re-used for the PANA-specific needs. This 607 is detailed in Section 5. 609 The present section defines additional PANA-specific objects that 610 extend the IPsec SPD MIB module in order to entirely satisfy the 611 PAA-EP interface requirements. 613 6.1. Bootstrapping link layer ciphers 615 PANA can bootstrap not only network layer secure access control but 616 also any type of link layer secure access control. The following 617 parameters are defined to support bootstrapping link layer secure 618 access control: 620 panaL2FiltPmk: 622 A PMK (Pairwise Master Key) that is derived from AAA-Key and used 623 as the shared secret needed for executing a secure association 624 protocol between the PaC and EP in order to generate TSKs 625 (Transient Session Keys) [I-D.ietf-eap-keying]. In the case of 626 IEEE 802.11i [802.11i], an 802.11i PMK is carried in this MIB 627 object. 629 PMK Name: 631 The name fo the PMK. In the case of IEEE 802.11i, a 802.11i PMKID 632 is carried in this MIB object. 634 PMK Lifetime: 636 The lifetime of the PMK. The PMK must be invalidated when the PMK 637 lifetime expires. A new PMK with a new PMK lifetime may be 638 installed before the lifetime of the current PMK expires. The PMK 639 lifetime may be calculated from a RADIUS Session-Timeout attribute 640 or a Diameter Authorization-Lifetime AVP. 642 These parameters are contained in PanaL2FilterEntry together with 643 other link layer filtering parameters. 645 6.2. Notification of PaC presence 647 The SPD-MIB provides a means to notify to the SNMP manager (PAA) 648 information on packets matching/not matching the filters of given 649 rule. Such notification mechanisms and objects can be re-used for 650 notifying the PAA that unauthorized packets are trying to pass 651 through the EP. 653 If reliability needs to be guaranteed for the notification 654 (panaNewPacNotification), hence Inform notification (which is 655 acknowledged) MUST be used. Then the PAA needs to have engine-id to 656 be the authoritative of SNMP clock between EP and PAA (for inform 657 operation the responder becomes the authoritative). 659 6.3. PANA MIB Overview 661 Link-Layer filter table 663 [I-D.ietf-pana-pana] says the Device-Id AVP (code 1025) is of 664 Address Type [RFC3588]. The content for link-layer addresses is 665 expected to be specified in specific documents that describe how 666 IP operates over different link-layers. For instance, IPv6 over 667 Ethernet is described in [RFC2464]. To this end, additional 668 filters are designed in the present document. The link-layer 669 filter test the L2 address (e.g. MAC address, port, DSL line) and 670 also defines a set of parameters needed for bootstrapping link- 671 layer ciphering, including a PMK (Pair-wise Master Key), the PMK 672 name and the PMK lifetime. Note that the definition of this table 673 does not assume the usage of any particular link-layer. 675 When the MIB module definition for a particular link-layer defines 676 MIB objects for the parameters specific to that link-layer, the 677 link-layer specific parameters SHOULD be accessed via the PANA MIB 678 using the link-layer filter table, instead of accessing them via 679 the link-layer specific MIB. 681 New PaC notification tables 683 This table defines a new notification, which aims at satisfying 684 this requirement. It re-uses existing notification variable 685 objects pre-defined in the SPD-MIB. 687 The "New PaC" notification is triggered when the EP detects 688 traffic coming from an unauthorized source. 690 If the traffic detected is an IP flow, the objects sent must 691 include spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, 692 and spdIPDestinationAddress objects to indicate the packet source 693 and destination of the packet that triggered the action. 694 Additionally, the spdIPInterfaceType and spdIPInterfaceAddress 695 objects are included to indicate which interface the action was 696 executed in association with and if the packet was inbound or 697 outbound through the endpoint. See [I-D.ietf-ipsp-spd-mib] for 698 further details. 700 If the traffic detected is Link-layer traffic, the objects sent 701 must include the index of the interface which detected such 702 traffic and potentially the L2 address source of the traffic. 704 6.4. PANA MIB Objects Definition 706 PANA-EP-MIB DEFINITIONS ::= BEGIN 708 IMPORTS 710 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE 711 FROM SNMPv2-SMI 713 TEXTUAL-CONVENTION, RowStatus, PhysAddress, StorageType, 714 TimeStamp, TimeInterval 715 FROM SNMPv2-TC 717 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 718 FROM SNMPv2-CONF 720 InterfaceIndex 721 FROM IF-MIB 723 spdMIB, spdIPEndpointAddType, spdIPEndpointAddress, 724 spdActionExecuted, spdIPSourceType, spdIPSourceAddress, 725 spdIPDestinationType,spdIPDestinationAddress 726 FROM IPSEC-SPD-MIB; 728 -- 729 -- Module identity 730 -- 732 panaMIB MODULE-IDENTITY 733 LAST-UPDATED 734 "200605280000Z" -- 28 may 2006 735 ORGANIZATION 736 "IETF PANA Working Group" 737 CONTACT-INFO 738 "Yacine El Mghazli 739 Alcatel 740 Route de Nozay 741 91460 Marcoussis 742 France 743 Email: yacine.el_mghazli@alcatel.fr 745 Yoshihiro Ohba 746 Toshiba America Research, Inc. 747 1, Telcordia Drive 748 Piscataway, NJ 08854 749 USA 750 Email: yohba@tari.toshiba.com" 751 DESCRIPTION 752 "The MIB module for defining additional PANA-specific objects to 753 the IPsec SPD MIB. Copyright (C) The Internet Society (2003). 754 This version of this MIB module is part of RFC XXXX, see the 755 RFC itself for full legal notices." 757 -- Revision History 758 REVISION 759 "200605280000Z" -- 28 may 2006 760 DESCRIPTION 761 "Removed L2 notif" 762 REVISION 763 "200512280000Z" -- 22 december 2005 764 DESCRIPTION 765 "L2 Filter indexing modified" 766 REVISION 767 "200506280000Z" -- 28 Juin 2005 768 DESCRIPTION 769 "L2 protection generic parameters" 770 REVISION 771 "200502050000Z" -- 05 February 2005 772 DESCRIPTION 773 "L2 generic filters" 774 REVISION 775 "200410220000Z" -- 22 October 2004 776 DESCRIPTION 777 "Version 02, draft-ietf-pana-snmp-02.txt" 778 REVISION 779 "200402050000Z" -- 05 February 2004 780 DESCRIPTION 781 "Version 01, draft-yacine-pana-paa2ep-snmp-01.txt" 782 REVISION 783 "200310310000Z" -- 31 October 2003 784 DESCRIPTION 785 "Initial version, draft-yacine-pana-paa2ep-snmp-00.txt" 786 ::= { spdMIB XXX } -- XXX to be assigned by IANA 788 -- 789 -- groups of related objects 790 -- 792 panaConfigObjects OBJECT IDENTIFIER 793 ::= { panaMIB 1 } 794 panaNotificationObjects OBJECT IDENTIFIER 795 ::= { panaMIB 2} 796 panaConformanceObjects OBJECT IDENTIFIER 798 ::= { panaMIB 3 } 800 -- 801 -- Textual Conventions 802 -- 804 PanaKey ::= TEXTUAL-CONVENTION 805 STATUS current 806 DESCRIPTION 807 "The PanaKey is used to carry a key. When the key does 808 not exist, the length of the key becomes zero." 809 SYNTAX OCTET STRING (SIZE(0..255)) 811 PanaKeyName ::= TEXTUAL-CONVENTION 812 STATUS current 813 DESCRIPTION 814 "The PanaKeyName is used to carry the name of a PanaKey. 815 When the key name does not exist, the length of the 816 key name becomes zero." 817 SYNTAX OCTET STRING (SIZE(0..255)) 819 -- 820 -- PANA Additional Filters Objects 821 -- 823 -- 824 -- The Link-layer Filter Table 825 -- 827 panaL2FilterTable OBJECT-TYPE 828 SYNTAX SEQUENCE OF PanaL2FilterEntry 829 MAX-ACCESS not-accessible 830 STATUS current 831 DESCRIPTION 832 "Link-layer filter definitions." 833 ::= { panaConfigObjects 1 } 834 panaL2FilterEntry OBJECT-TYPE 835 SYNTAX PanaL2FilterEntry 836 MAX-ACCESS not-accessible 837 STATUS current 838 DESCRIPTION 839 "An entry in the Link-layer filter table." 840 INDEX { panaL2FiltEpIfIndex, panaL2FiltAddr } 841 ::= { panaL2FilterTable 1 } 843 PanaL2FilterEntry ::= SEQUENCE { 844 panaL2FiltEpIfIndex InterfaceIndex, 845 panaL2FiltAddr PhysAddress, 846 panaL2FiltPmk PanaKey, 847 panaL2FiltPmkName PanaKeyName, 848 panaL2FiltPmkLifetime TimeInterval, 849 panaL2FiltLastChanged TimeStamp, 850 panaL2FiltStorageType StorageType, 851 panaL2FiltRowStatus RowStatus 852 } 854 panaL2FiltEpIfIndex OBJECT-TYPE 855 SYNTAX InterfaceIndex 856 MAX-ACCESS read-create 857 STATUS current 858 DESCRIPTION 859 "The index identifying the EP interface where the filter 860 policy must be enforced on." 861 ::= { panaL2FilterEntry 1 } 863 panaL2FiltAddr OBJECT-TYPE 864 SYNTAX PhysAddress 865 MAX-ACCESS read-create 866 STATUS current 867 DESCRIPTION 868 "The authorized device Link-layer address (DI). For 869 example, for a 802.x interface, this object normally 870 contains a MAC address. For interfaces which do not have such 871 an address (e.g., a serial line), this object should contain 872 an octet string of zero length." 873 ::= { panaL2FilterEntry 2 } 875 panaL2FiltPmk OBJECT-TYPE 876 SYNTAX PanaKey 877 MAX-ACCESS read-create 878 STATUS current 879 DESCRIPTION 880 "This is PMK (Pairwise Master Key) used for bootstraping 881 link-layer ciphers." 882 ::= { panaL2FilterEntry 3 } 884 panaL2FiltPmkName OBJECT-TYPE 885 SYNTAX PanaKeyName 886 MAX-ACCESS read-create 887 STATUS current 888 DESCRIPTION 889 "This is the name of the panaL2Pmk." 890 ::= { panaL2FilterEntry 4 } 892 panaL2FiltPmkLifetime OBJECT-TYPE 893 SYNTAX TimeInterval 894 MAX-ACCESS read-create 895 STATUS current 896 DESCRIPTION 897 "This is the lifetime of panaL2Pmk." 898 ::= { panaL2FilterEntry 5 } 900 panaL2FiltLastChanged OBJECT-TYPE 901 SYNTAX TimeStamp 902 MAX-ACCESS read-only 903 STATUS current 904 DESCRIPTION 905 "The value of sysUpTime when this row was last modified or 906 created either through SNMP SETs or by some other external 907 means." 908 ::= { panaL2FilterEntry 6 } 910 panaL2FiltStorageType OBJECT-TYPE 911 SYNTAX StorageType 912 MAX-ACCESS read-create 913 STATUS current 914 DESCRIPTION 915 "The storage type for this row. Rows in this table which were 916 created through an external process may have a storage type 917 of readOnly or permanent." 918 DEFVAL { nonVolatile } 919 ::= { panaL2FilterEntry 7 } 921 panaL2FiltRowStatus OBJECT-TYPE 922 SYNTAX RowStatus 923 MAX-ACCESS read-create 924 STATUS current 925 DESCRIPTION 926 "This object indicates the conceptual status of this row." 927 ::= { panaL2FilterEntry 8 } 928 -- 929 -- 930 -- Notification objects information 932 -- 933 -- 935 panaNotificationVariables OBJECT IDENTIFIER ::= 936 { panaNotificationObjects 1 } 938 panaNotifications OBJECT IDENTIFIER ::= 940 { panaNotificationObjects 0 } 942 panaEpIfIndex OBJECT-TYPE 943 SYNTAX InterfaceIndex 944 MAX-ACCESS accessible-for-notify 945 STATUS current 946 DESCRIPTION 947 "Contains the interface index on which the packet triggered 948 the notification in question." 949 ::= { panaNotificationVariables 1 } 951 panaL2SourceAddress OBJECT-TYPE 952 SYNTAX PhysAddress 953 MAX-ACCESS accessible-for-notify 954 STATUS current 955 DESCRIPTION 956 "Contains the source Link layer address of the packet which 957 triggered the notification in question. For 958 example, for a 802.x frame, this object normally 959 contains a MAC address. For interfaces which do not have such 960 an address (e.g., a serial line), this object should contain 961 an octet string of zero length." 962 ::= { panaNotificationVariables 2 } 964 panaNewPacNotification NOTIFICATION-TYPE 965 OBJECTS { 966 spdActionExecuted, 967 spdIPEndpointAddType, 968 spdIPEndpointAddress, 969 spdIPSourceType, 970 spdIPSourceAddress, 971 spdIPDestinationType, 972 spdIPDestinationAddress, 973 panaEpIfIndex, 974 panaL2SourceAddress} 975 STATUS current 976 DESCRIPTION 977 "Notification that EP detected traffic coming from an 978 unauthorized source. When source and destination IP addresses 979 of the traffic is unknown, spdIPSourceType and 980 spdIPDestinationType must be zero. When source L2 address of 981 the traffic is unknown, panaL2SourceAddress must be zero.Notification 982 that EP detected traffic coming from an 983 unauthorized source." 984 ::= { panaNotifications 1 } 986 -- 987 -- 988 -- Conformance information 989 -- 990 -- 992 panaGroups OBJECT IDENTIFIER 993 ::= { panaConformanceObjects 1 } 994 panaCompliances OBJECT IDENTIFIER 995 ::= { panaConformanceObjects 2 } 997 -- 998 -- Compliance Groups Definitions 999 -- 1001 panaL2FilterGroup OBJECT-GROUP 1002 OBJECTS { 1003 panaL2FiltEpIfIndex, 1004 panaL2FiltAddr, 1005 panaL2FiltPmk, 1006 panaL2FiltPmkName, 1007 panaL2FiltPmkLifetime, 1008 panaL2FiltLastChanged, 1009 panaL2FiltStorageType, 1010 panaL2FiltRowStatus } 1011 STATUS current 1012 DESCRIPTION 1013 "The Link-layer Filter Group." 1014 ::= { panaGroups 1 } 1016 panaNewPacNotificationObjectsGroup OBJECT-GROUP 1017 OBJECTS { 1018 panaEpIfIndex, 1019 panaL2SourceAddress } 1020 STATUS current 1021 DESCRIPTION 1022 "PaC Presence Notification Objects Group." 1023 ::= { panaGroups 2 } 1025 panaNewPacNotificationGroup NOTIFICATION-GROUP 1026 NOTIFICATIONS { 1027 panaNewPacNotification} 1028 STATUS current 1029 DESCRIPTION 1030 "PaC Presence Notification Group." 1031 ::= { panaGroups 3 } 1033 -- 1034 -- Compliance statements 1035 -- 1037 panaFilterCompliance MODULE-COMPLIANCE 1038 STATUS current 1039 DESCRIPTION 1040 "The compliance statement for SNMP entities that support 1041 PANA DI-based filtering." 1043 MODULE -- This Module 1045 MANDATORY-GROUPS { panaL2FilterGroup } 1047 OBJECT panaL2FiltRowStatus 1048 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1049 DESCRIPTION 1050 "Support of the values notInService(2), notReady(3), 1051 and createAndWait(5) is not required." 1053 OBJECT panaL2FiltLastChanged 1054 MIN-ACCESS not-accessible 1055 DESCRIPTION 1056 "This object not required for compliance." 1058 MODULE IPSEC-SPD-MIB 1060 MANDATORY-GROUPS { 1061 spdEndpointGroup, 1062 spdGroupContentsGroup, 1063 spdRuleDefinitionGroup, 1064 spdStaticFilterGroup, 1065 spdStaticActionGroup } 1067 OBJECT spdEndGroupRowStatus 1068 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1069 DESCRIPTION 1070 "Support of the values notInService(2), notReady(3), 1071 and createAndWait(5) is not required." 1073 OBJECT spdEndGroupLastChanged 1074 MIN-ACCESS not-accessible 1075 DESCRIPTION 1076 "This object not required for compliance." 1078 OBJECT spdGroupContComponentType 1079 SYNTAX INTEGER { rule(2) } 1080 DESCRIPTION 1081 "Support of the value group(1) is only required for 1082 implementations which support Policy Groups within 1083 Policy Groups." 1085 OBJECT spdGroupContRowStatus 1086 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1087 DESCRIPTION 1088 "Support of the values notInService(2), notReady(3), 1089 and createAndWait(5) is not required." 1091 OBJECT spdGroupContLastChanged 1092 MIN-ACCESS not-accessible 1093 DESCRIPTION 1094 "This object not required for compliance." 1096 OBJECT spdRuleDefRowStatus 1097 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1098 DESCRIPTION 1099 "Support of the values notInService(2), notReady(3), 1100 and createAndWait(5) is not required." 1102 OBJECT spdRuleDefLastChanged 1103 MIN-ACCESS not-accessible 1104 DESCRIPTION 1105 "This object not required for compliance." 1107 ::= { panaCompliances 1 } 1108 panaNewPacNotificationCompliance MODULE-COMPLIANCE 1109 STATUS current 1110 DESCRIPTION 1111 "The compliance statement for SNMP entities that support 1112 new PaC presence Notification." 1114 MODULE -- This Module 1116 MANDATORY-GROUPS { 1117 panaNewPacNotificationObjectsGroup, 1118 panaNewPacNotificationGroup 1119 } 1121 MODULE IPSEC-SPD-MIB 1123 MANDATORY-GROUPS { spdActionLoggingObjectGroup } 1125 ::= { panaCompliances 2 } 1127 END 1129 7. Applicability of RTFM Meter MIB 1131 RTFM provides for the measurement of network traffic flows: 1133 o a method of specifying traffic flows within a network 1135 o a hierarchy of devices (meters, meter readers, managers) for 1136 measuring the specified flows 1138 o a mechanism for configuring meters and meter readers, and for 1139 collecting the flow data from remote meters 1141 RTFM provides high time resolution for flow first- and last-packet 1142 times. Counters for long-duration flows may be read at intervals 1143 determined by a manager. The RTFM Meter is designed so as to do as 1144 much data reduction work as possible, which minimizes the amount of 1145 data to be read and the amount of processing needed to produce useful 1146 reports from it. 1148 RTFM flow data can be used for a wide range of purposes, such as 1149 usage accounting, long-term recording of network usage (classified by 1150 IP address attributes) and real-time analysis of traffic flows at 1151 remote metering points. 1153 PANA recommends the use of the following RTFM module and architecture 1154 for the PAA to collect accounting information from the EP(s). It is 1155 the responsability of the PAA to organise the correlation between the 1156 EP filters, RTFM flows, the PANA and the AAA sessions. 1158 RTFM Meter MIB [RFC2720] describes the SNMP Management Information 1159 Base for an RTFM meter, including its flow table, rule table (storing 1160 the meter's rulesets) and the control tables used for managing a 1161 meter and reading flow data from it. 1163 [RFC2722] defines the RTFM Architecture, giving descriptions of each 1164 component. Explains how traffic flows are viewed as logical entities 1165 described in terms of their address-attribute values, so that each is 1166 defined by the attributes of its end-points. Gives a detailed 1167 description of the RTFM traffic meter, with full details of how flows 1168 are stored in the meter's flow table, and how packets are matched in 1169 accordance with rules stored in a ruleset. 1171 8. EP Configuration Example 1173 Below are usage examples of the MIB modules in the PANA context. 1175 8.1. Common setup 1177 The "EndPoint to Group" table is used to map policy (groupings) onto 1178 an endpoint (EP-ADDR is the IP address) where traffic is to pass by. 1179 Any policy group assigned to an endpoint is then used to control 1180 access to the traffic passing by it. 1182 So far, we define below two policy groups at the EP interface ("EP- 1183 SPD-IN" and "EP-SPD-OUT"). 1185 spdEndpointToGroupTable, row 1: 1187 o spdEndGroupDirection = incoming; 1189 o spdEndGroupIdentType = IPv4; 1191 o spdEndGroupAddress = EP-ADDR; 1193 o spdEndGroupName = "EP-SPD-IN"; 1195 spdEndpointToGroupTable, row 2: 1197 o spdEndGroupDirection = outgoing; 1199 o spdEndGroupIdentType = IPv4; 1201 o spdEndGroupAddress = EP-ADDR; 1203 o spdEndGroupName = "EP-SPD-OUT"; 1205 Within each of the policy group defined above, we define a sub-group 1206 (a compound filter) dedicated to the treatment of traffic that is 1207 allowed prior to any configuration. The following configuration 1208 illustrates the incoming allowed unprotected traffic: 1210 spdGroupContentsTable, row 1: 1212 o spdGroupContName = "EP-SPD-IN"; 1214 o spdGroupContPriority = '10'; 1216 o spdGroupContFilter = spdTrueFilterInstance; 1217 o spdGroupContComponentType = group; 1219 o spdGroupContComponentName = "EP-ALLOWED-UNPROTECTED-IN"; 1221 Within this sub-group, we define a rule (a sub-filter) dedicated to 1222 each allowed traffic types (namely PANA, ARP, IPv6 Neighbor 1223 Discovery, DHCP, etc). The following configuration illustrates the 1224 case of incoming DHCP traffic: 1226 spdGroupContentsTable, row 2: 1228 o spdGroupContName = "EP-ALLOWED-UNPROTECTED-IN"; 1230 o spdGroupContPriority = '1'; 1232 o spdGroupContFilter = diffServMultiFieldClfrTable.10; 1234 o spdGroupContComponentType = rule; 1236 o spdGroupContComponentName = "EP-DHCP-ACCEPT-IN"; 1238 We define the corresponding filter in the DiffServ Multi-Field 1239 Classifier table (DIFFSERV_MIB, [RFC3289]), which matches the DHCP 1240 packets: 1242 diffServMultiFieldClfrTable, row 10: 1244 o diffServMultiFieldClfrAddrType = v4; 1246 o diffServMultiFieldClfrSrcL4PortMin = '546' (DHCP); 1248 o diffServMultiFieldClfrSrcL4PortMax = '547' (DHCP); 1250 o diffServMultiFieldClfrProtocol = '17' (UDP); 1252 The "Rule Defininition" table links a rule with a given action in the 1253 SPD action MIB. E.g. the following entries links the filter defined 1254 above with the "accept" action statically defined in the SPD MIB 1255 (spdStaticActions.3). 1257 spdRuleDefinitionTable, row 1: 1259 o spdRuleDefName = "EP-DHCP-ACCEPT-IN"; 1261 o spdRuleDefDescription = "Allow Incoming DHCP packets"; 1263 o spdRuleDefFilter = spdTrueFilterInstance; 1264 o spdRuleDefFilterNegated = false (default); 1266 o spdRuleDefAction = spdAcceptAction; 1268 8.2. General IP-based Access Control 1270 In this section, we need to configure the SPD so that EP accepts IP 1271 packets coming from/going to the client 'PaC1'. In the whole 1272 section, 'PaC1-IP@' is the IP address of 'PaC1'. 1274 Within the incoming policy group defined above ("EP-SPD-IN"), we 1275 define a rule dedicated to the treatment of packets coming from 1276 "PaC1" and the EP we are provisioning. 1278 spdGroupContentsTable, row 3: 1280 o spdGroupContName = "EP-SPD-IN"; 1282 o spdGroupContPriority = '100'; 1284 o spdGroupContFilter = diffServMultiFieldClfrTable.1; 1286 o spdGroupContComponentType = rule; 1288 o spdGroupContComponentName = "EP-PaC1-ACCEPT-IN"; 1290 We define the filter in the DiffServ Multi-field Classifier table, 1291 which matches IP packets coming from the PaC: 1293 diffServMultiFieldClfrTable, row 1: 1295 o diffServMultiFieldClfrAddrType = v4; 1297 o diffServMultiFieldClfrSrcAddr = 'PaC1-IP@'; 1299 diffServMultiFieldClfrTable, row 2: 1301 o diffServMultiFieldClfrAddrType = v4; 1303 o diffServMultiFieldClfrDstAddr = 'PaC1-IP@'; 1305 The following entries links the two filters defined above with the 1306 "accept" action. 1308 spdRuleDefinitionTable, row 2: 1310 o spdRuleDefName = "EP-PaC1-ACCEPT-IN"; 1311 o spdRuleDefDescription = "Allow Incoming IP packets from PaC1"; 1313 o spdRuleDefFilter = spdTrueFilterInstance; 1315 o spdRuleDefFilterNegated = false (default); 1317 o spdRuleDefAction = spdAcceptAction; 1319 spdRuleDefinitionTable, row 3: 1321 o spdRuleDefName = "EP-PaC1-ACCEPT-OUT"; 1323 o spdRuleDefDescription = "Allow Outgoing IP packets to PaC1"; 1325 o spdRuleDefFilter = spdTrueFilterInstance; 1327 o spdRuleDefFilterNegated = false (default); 1329 o spdRuleDefAction = spdAcceptAction; 1331 The same thing must be done for the outgoing direction and this 1332 results in a policy such that any packet coming from/going to the PaC 1333 is allowed to go through the EP (via EP-ADDR endpoint). 1335 8.3. IPsec-based Access Control 1337 In this section we consider the case when IPsec is used to control 1338 access at the IP level. In order to avoid many redundancies, the 1339 previous configuration set is still valid. See below a usage example 1340 of IKEACTION-MIB and IPSECACTION-MIB. 1342 -- IKE Phase 1 configuration (agressive mode): 1344 We define a first-level filter in policy group "EP-SPD-IN" of the SPD 1345 MIB, using the "Group contents" table. This filter isolates IKE 1346 phase 1 traffic coming to the EP on this interface: 1348 spdGroupContentsTable, row 4: 1350 o spdGroupContName = "EP-SPD-IN"; 1352 o spdGroupContPriority = '1'; 1354 o spdGroupContFilter = ipiaIkePhase1Filter; 1356 o spdGroupContComponentType = group; 1357 o spdGroupContComponentName = "EP-IKE1-IN"; 1359 Within this IKE-specific policy sub-group, we specify a second-level 1360 filter to apply for for the traffic coming from PaC1. 1362 spdGroupContentsTable, row 5: 1364 o spdGroupContName = "EP-IKE-Phase1-IN"; 1366 o spdGroupContPriority = '1'; 1368 o spdGroupContFilter = diffServMultiFieldClfrTable.1; 1370 o spdGroupContComponentType = group; 1372 o spdGroupContComponentName = "EP-IKE1-PaC1-IN"; 1374 The diffServMultiFieldClfrTable.1 entry has been defined in the 1375 previous section. Within the lattest sub-group we finally specify 1376 the rule to apply for the IKE traffic coming from PaC1 and matching 1377 the right identity (id_key_id). 1379 spdGroupContentsTable, row 6: 1381 o spdGroupContName = "EP-IKE1-PaC1-IN"; 1383 o spdGroupContPriority = '1'; 1385 o spdGroupContFilter = ipiaPeerIdentityFilterTable.1; 1387 o spdGroupContComponentType = rule; 1389 o spdGroupContComponentName = "PaC1-IKE1-RULE"; 1391 The "Peer Identity Filter" table specifically informs the EP on the 1392 value of the idKeyId to use in IKE messages: 1394 ipiaPeerIdentityFilterTable, row 1: 1396 o ipiaPeerIdFiltName = "PaC1-IKE1-ID-FILTER"; 1398 o ipiaPeerIdFiltIdentityType = id_Key_Id; 1400 o ipiaPeerIdFiltIdentityValue = 'PANA-Session-Id|PANA-Key-Id'; 1402 The "Rule Defininition" table links a rule with a given action in the 1403 IKE action MIB. This action will be triggered upon reception at the 1404 EP of an IKE phase 1 packet coming from PaC1 and matching the right 1405 id_key_id. 1407 spdRuleDefinitionTable, row 4: 1409 o spdRuleDefName = "PaC1-IKE-RULE"; 1411 o spdRuleDefDescription = "IPsec Access Control for PaC1"; 1413 o spdRuleDefFilter = spdTrueFilterInstance; 1415 o spdRuleDefFilterNegated = false (default); 1417 o spdRuleDefAction = ipiaIkeActionTable.1; 1419 The spdRuleDefAction attribute in the entry above points to a row in 1420 the ipiaIkeActionTable, defined below: 1422 ipiaIkeActionTable, row 1: 1424 o ipiaIkeActName = "PaC1-IKE"; 1426 o ipiaIkeActParametersName = "SA1-PaC1"; 1428 o ipiaIkeActThresholdDerivedKeys = '100' (default); 1430 o ipiaIkeActExchangeMode = aggressive; 1432 o ipiaIkeActAgressiveModeGroupId = 'xxx' (Diffie-Hellman values); 1434 o ipiaIkeActIdentityType = id_Key_Id; 1436 o ipiaIkeActIdentityContext = "PANA"; 1438 o ipiaIkeActPeerName = "PaC1"; 1440 The following entry links together the "PaC1" identity with the 1441 corresponding credentials table entry: 1443 ipiaIkeIdentityTable, row 1: 1445 o spdEndGroupIdentType = IPv4; 1447 o spdEndGroupAddress = 'EP-ADDR'; 1449 o ipiaIkeActIdentityType = id_Key_Id; 1451 o ipiaIkeActIdentityContext = 'PANA'; 1452 o ipiaIkeIdCredentialName = "PaC1-PSK"; 1454 Finally, the pre-shared key derivated at the PAA is set in the IPSA 1455 Credentials table (IPSECACTION-MIB): 1457 ipsaCredentialTable, row 1: 1459 o ipsaCredName = "PaC1-PSK"; 1461 o ipsaCredType = sharedSecret; 1463 o ipsaCredCredential = 'PSK-derived-at-the-PAA'; 1465 o ipsaCredSize = 'xxx'; 1467 o ipsaMgnName = "xxx"; 1469 o ipsaRemoteID = 'PaC1'; 1471 The Ike Action entry (above) is indexed by a name (ipiaIkeActName 1472 attribute), which is used as the primary index into the 1473 ipiaIkeActionProposalsTable. The secondary index is a priority, 1474 which allows ordering of the proposals that will be sent to the peer 1475 (or accepted from the peer). 1477 ipiaIkeActionProposalsTable, row 1: 1479 o ipiaIkeActPropName = "PaC1-IKE-PROP1"; 1481 o ipiaIkeActPropPriority = '1'; 1483 The ipiaIkeActPropName points to a row in the ipiaIkeProposalsTable, 1484 which contains the actual IKE parameters for the Phase 1 exchanges: 1486 ipiaIkeProposalsTable, row 1: 1488 o ipiaIkeActPropName = "PaC1-IKE-PROP1"; 1490 o ipiaIkePropLifetimeDerivedKeys = xxx; 1492 o ipiaIkePropCipherAlgorithm = 3DES; 1494 o ipiaIkePropCipherKeyLength = xxx; 1496 o ipiaIkePropHashAlgorithm = HMAC-SHA1; 1498 o ipiaIkePropPrfAlgorithm = xxx; 1499 o ipiaIkePropVendorId = xxx; 1501 o ipiaIkePropDhGroup = 2; 1503 o ipiaIkePropAuthenticationMethod = xxx; 1505 o ipiaIkePropMaxLifetimeSecs = xxx; 1507 o ipiaIkePropMaxLifetimeKB = xxx; 1509 There is a similar hierarchy for the proposals, which are used for 1510 Phase 2 negotiations, and result in a Phase 2 SA being created, upon 1511 successful negotiations. The parameters would be set up in the 1512 ipiaIpsecActionTable, ipiaIpsecProposalsTable and 1513 ipiaIpsecTransformsTable, along with the necessary related tables. 1514 One would then need a rule to trigger the row in the 1515 ipiaIpsecActionTable. See for further details on the IPSP MIBs 1516 usage. 1518 8.4. Link-layer Access control 1520 The section below gives a usage example of the PANA module in the 1521 general L2-based access control case. 1523 The example below assumes the configuration set detailed in 1524 Section 8.1 is valid. Here we need to configure the SPD so that EP 1525 accepts accepts 802 packets coming from/going to the client 'PaC1'? 1526 In the whole section 'PaC1-MAC@' is the MAC address of 'PaC1'. 1528 Within the incoming policy group defined above ("EP-SPD-IN"), we 1529 define a rule dedicated to the treatment of packets coming from 1530 "PaC1" and the EP we are provisioning. 1532 spdGroupContentsTable, row 3: 1534 o spdGroupContName = "EP-SPD-IN"; 1536 o spdGroupContPriority = '101'; 1538 o spdGroupContFilter = panaL2FilterTable.1; 1540 o spdGroupContComponentType = rule; 1542 o spdGroupContComponentName = "EP-PaC1-ACCEPT-IN-L2"; 1544 We define the filter in the Link-layer filter table, which matches L2 1545 packets coming from the PaC to interface #5, which a 802.11 1546 interface: 1548 panaL2FilterTable, row 1: 1550 o panaL2FiltEpIfIndex = 5; 1552 o panaL2FiltAddr = "00-11-0A-80-4A-58"; 1554 o panaL2FiltPmk = "..."; 1556 o panaL2FiltPmkName = "..."; 1558 o panaL2FiltPmkLifetime = 10800; 1560 The following entries links the filter defined above with the 1561 "accept" action. 1563 spdRuleDefinitionTable, row 20: 1565 o spdRuleDefName = "EP-PaC1-ACCEPT-IN-L2"; 1567 o spdRuleDefDescription = "Allow Incoming L2 packets from PaC1 via 1568 Interface #5"; 1570 o spdRuleDefFilter = spdTrueFilterInstance; 1572 o spdRuleDefFilterNegated = false (default); 1574 o spdRuleDefAction = spdAcceptAction; 1576 The same thing must be done for the outgoing direction and this 1577 results in a policy such that any packet coming from/going to the PaC 1578 is allowed to go through the EP. 1580 9. Security Considerations 1582 The MIB defined in the present document relates to a system which 1583 will provide network access. As such, improper manipulation of the 1584 objects represented by this MIB may result in denial of service to a 1585 large number of end-users. In addition, manipulation of the 1586 panaL2FilterTable and diffServMultiFieldClfrTable may allow an end- 1587 user to gain network access, spoof their IP addresses, change the 1588 authorized device identifiers, or affect other end-users in either a 1589 positive or negative manner. 1591 There are a number of management objects defined in this MIB module 1592 with a MAX-ACCESS clause of read-write and/or read-create. Such 1593 objects may be considered sensitive or vulnerable in some network 1594 environments. The support for SET operations in a non-secure 1595 environment without proper protection can have a negative effect on 1596 network operations. These are the tables and objects and their 1597 sensitivity/vulnerability: 1599 o The use of panaL2FilterTable to specify which Link-layer addresses 1600 are authorized to access the network on which interface is 1601 considered to be only limited protection and does not protect 1602 against attacks which spoof the management station's IP address. 1603 The use of SNMPv3 security is mandated. Specifically, SNMPv3 VACM 1604 and USM MUST be used with any v3 agent which implements this MIB. 1606 As described in Section 2.1, it is assumed that PAA and EP are pre- 1607 configured to be able to communicate each other with a required 1608 security association. The pre-configured SNMP user passphrase for 1609 the security association between PAA and EP should not be used for a 1610 long term and should be updated at a reasonable frequency. 1612 It might be sufficient to use the same SNMP user identity and 1613 passphrase for all EPs controlled by the same PAA (the same thing can 1614 apply even when the EPs are controlled by multiple PAAs.) Note that 1615 even if the same SNMP user identity and passphrase for all EPs are 1616 used, the different SNMP authentication and encryption keys are 1617 derived for each EP, because the combination of SNMP user identity 1618 and engine-id is used for deriving the keys. 1620 SNMP versions prior to SNMPv3 did not include adequate security. 1621 Even if the network itself is secure (for example by using IPsec), 1622 even then, there is no control as to who on the secure network is 1623 allowed to access and GET/SET (read/change/create/delete) the objects 1624 in this MIB module. 1626 It is RECOMMENDED that implementers consider the security features as 1627 provided by the SNMPv3 framework (see [RFC3410], section 8), 1628 including full support for the SNMPv3 cryptographic mechanisms (for 1629 authentication and privacy). 1631 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1632 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1633 enable cryptographic security. It is then a customer/operator 1634 responsibility to ensure that the SNMP entity giving access to an 1635 instance of this MIB module is properly configured to give access to 1636 the objects only to those principals (users) that have legitimate 1637 rights to indeed GET or SET (change/create/delete) them. 1639 10. IANA Considerations 1641 The only IANA considerations for this document is the node number 1642 allocation of the PANA-EP-MIB itself. 1644 11. Acknowledgements 1646 The authors would like to thank David Perkins for the MIB deep 1647 inspection and Robert Story, who provided very helpful 1648 recommendations on the IPSP MIBs usage. 1650 This document originaly leverages on similar works done in the MIDCOM 1651 working group. Thanks to the authors of those IDs. Thanks to Thomas 1652 Moore and Olivier Marce for their grateful help during the edition of 1653 this document. 1655 12. References 1657 12.1. Normative References 1659 [I-D.ietf-pana-pana] 1660 Forsberg, D., "Protocol for Carrying Authentication for 1661 Network Access (PANA)", draft-ietf-pana-pana-11 (work in 1662 progress), March 2006. 1664 [I-D.ietf-pana-ipsec] 1665 Parthasarathy, M., "PANA Enabling IPsec based Access 1666 Control", draft-ietf-pana-ipsec-07 (work in progress), 1667 July 2005. 1669 [I-D.ietf-ipsp-spd-mib] 1670 Hardaker, W., "IPsec Security Policy Database 1671 Configuration MIB", draft-ietf-ipsp-spd-mib-06 (work in 1672 progress), April 2006. 1674 [I-D.ietf-ipsp-ikeaction-mib] 1675 Hardaker, W., "IPsec Security Policy IKE Action MIB", 1676 draft-ietf-ipsp-ikeaction-mib-01 (work in progress), 1677 August 2005. 1679 [I-D.ietf-ipsp-ipsecaction-mib] 1680 Hardaker, W., "IPsec Security Policy IPsec Action MIB", 1681 draft-ietf-ipsp-ipsecaction-mib-01 (work in progress), 1682 August 2005. 1684 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1685 Schoenwaelder, Ed., "Structure of Management Information 1686 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1688 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1689 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1690 STD 58, RFC 2579, April 1999. 1692 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1693 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1694 April 1999. 1696 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1697 Base for the Differentiated Services Architecture", 1698 RFC 3289, May 2002. 1700 12.2. Informative References 1702 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1703 "Protocol for Carrying Authentication for Network Access 1704 (PANA) Requirements", RFC 4058, May 2005. 1706 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1707 and Network Access (PANA) Threat Analysis and Security 1708 Requirements", RFC 4016, March 2005. 1710 [I-D.ietf-pana-framework] 1711 Jayaraman, P., "PANA Framework", 1712 draft-ietf-pana-framework-06 (work in progress), 1713 March 2006. 1715 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1716 (USM) for version 3 of the Simple Network Management 1717 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1719 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1720 "Introduction and Applicability Statements for Internet- 1721 Standard Management Framework", RFC 3410, December 2002. 1723 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1724 Architecture for Describing Simple Network Management 1725 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1726 December 2002. 1728 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1729 Internet Protocol", RFC 2401, November 1998. 1731 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1732 (IKE)", RFC 2409, November 1998. 1734 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1735 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1737 [I-D.ietf-aaa-diameter-cc] 1738 Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 1739 Hakala, "Diameter Credit-control Application", 1740 draft-ietf-aaa-diameter-cc-06 (work in progress), 1741 August 2004. 1743 [I-D.ietf-eap-keying] 1744 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1745 Management Framework", draft-ietf-eap-keying-13 (work in 1746 progress), May 2006. 1748 [802.11i] IEEE P802, "Wireless MAC and PHY specifications, MAC 1749 security enhancements", IEEE 802.11i, July 2004. 1751 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1752 Networks", RFC 2464, December 1998. 1754 [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 1755 RFC 2720, October 1999. 1757 [RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow 1758 Measurement: Architecture", RFC 2722, October 1999. 1760 Authors' Addresses 1762 Yacine El Mghazli (Editor) 1763 Alcatel 1764 Route de Nozay 1765 Marcoussis 91460 1766 France 1768 Email: yacine.el_mghazli@alcatel.fr 1770 Yoshihiro Ohba 1771 Toshiba America Research, Inc. 1772 1, Telcordia Drive 1773 Piscataway, NJ 08854 1774 USA 1776 Email: yohba@tari.toshiba.com 1778 Julien Bournelle 1779 GET/INT 1780 9, rue Charles Fourier 1781 Evry 91011 1782 France 1784 Email: julien.bournelle@int-evry.fr 1786 Intellectual Property Statement 1788 The IETF takes no position regarding the validity or scope of any 1789 Intellectual Property Rights or other rights that might be claimed to 1790 pertain to the implementation or use of the technology described in 1791 this document or the extent to which any license under such rights 1792 might or might not be available; nor does it represent that it has 1793 made any independent effort to identify any such rights. Information 1794 on the procedures with respect to rights in RFC documents can be 1795 found in BCP 78 and BCP 79. 1797 Copies of IPR disclosures made to the IETF Secretariat and any 1798 assurances of licenses to be made available, or the result of an 1799 attempt made to obtain a general license or permission for the use of 1800 such proprietary rights by implementers or users of this 1801 specification can be obtained from the IETF on-line IPR repository at 1802 http://www.ietf.org/ipr. 1804 The IETF invites any interested party to bring to its attention any 1805 copyrights, patents or patent applications, or other proprietary 1806 rights that may cover technology that may be required to implement 1807 this standard. Please address the information to the IETF at 1808 ietf-ipr@ietf.org. 1810 Disclaimer of Validity 1812 This document and the information contained herein are provided on an 1813 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1814 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1815 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1816 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1817 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1818 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1820 Copyright Statement 1822 Copyright (C) The Internet Society (2006). This document is subject 1823 to the rights, licenses and restrictions contained in BCP 78, and 1824 except as set forth therein, the authors retain all their rights. 1826 Acknowledgment 1828 Funding for the RFC Editor function is currently provided by the 1829 Internet Society.