idnits 2.17.1 draft-ietf-pana-snmp-05.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 1805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1795. ** 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 : ---------------------------------------------------------------------------- ** 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 640: '...is acknowledged) MUST be used. Then t...' RFC 2119 keyword, line 663: '...cific parameters SHOULD be accessed vi...' RFC 2119 keyword, line 1591: '... and USM MUST be used with any v3...' RFC 2119 keyword, line 1613: '... It is RECOMMENDED that implementers...' RFC 2119 keyword, line 1619: '... 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 (January 5, 2006) is 6686 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-10 == Outdated reference: A later version (-07) exists of draft-ietf-ipsp-spd-mib-03 == 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-05 -- 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-08 Summary: 4 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: July 9, 2006 Y. Ohba 5 Toshiba 6 J. Bournelle 7 GET/INT 8 January 5, 2006 10 SNMP usage for PAA-EP interface 11 draft-ietf-pana-snmp-05 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 July 9, 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 . . . . . . . . . . . . . . . 10 70 4.2.6. Peer Liveness Test and Rebooted Peer Detection . . . . 11 71 5. Applicability of IPsec configuration MIBs . . . . . . . . . . 12 72 5.1. General IP Access Control . . . . . . . . . . . . . . . . 12 73 5.2. Network Layer Secure Access Control (IPsec) . . . . . . . 13 74 6. PANA extension to the IPsec SPD MIB . . . . . . . . . . . . . 16 75 6.1. Bootstrapping link layer ciphers . . . . . . . . . . . . . 16 76 6.2. Notification of PaC presence . . . . . . . . . . . . . . . 16 77 6.3. PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 17 78 6.4. PANA MIB Objects Definition . . . . . . . . . . . . . . . 18 79 7. Applicability of RTFM Meter MIB . . . . . . . . . . . . . . . 28 80 8. EP Configuration Example . . . . . . . . . . . . . . . . . . . 29 81 8.1. Common setup . . . . . . . . . . . . . . . . . . . . . . . 29 82 8.2. General IP-based Access Control . . . . . . . . . . . . . 31 83 8.3. IPsec-based Access Control . . . . . . . . . . . . . . . . 32 84 8.4. Link-layer Access control . . . . . . . . . . . . . . . . 36 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 43 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 92 Intellectual Property and Copyright Statements . . . . . . . . . . 46 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 4.2.5. Accounting Consideration 387 Since authentication and authorization are closely related to 388 accounting in many cases, accounting aspects need to be considered in 389 the PAA-EP protocol. 391 The PAA device acts as an accounting client of a AAA protocol. The 392 PAA collects accounting information from the EP(s) it controls, and 393 sends the gathered data to the accounting server by using the AAA 394 protocol. 396 PANA accounting management can be done using RTFM (Real-Time Flow 397 Measurement) standard MIB module [RFC2720], this is detailed in 398 Section 7. 400 The authentication/authorization session identifier of a AAA protocol 401 is used by the accounting server to associate accounting information 402 with a particular authentication/authorization session to calculate 403 bills. The authentication/authorization session identifier may or 404 may not be the same as the PANA session identifier and it is the 405 responsibility of the PAA to organize the correlation between the 406 meters/filters at the EP and the PANA/AAA sessions at the PAA. 408 The communicating pair of the PAA and the EP might need to detect a 409 rebooted peer to avoid possible inaccurate accounting. This aspect 410 is discussed in Section 4.2.6. 412 4.2.6. Peer Liveness Test and Rebooted Peer Detection 414 PAA-EP protocol implementations need to be stateful, when considering 415 the authorization and accounting aspects as described in the previous 416 sections. The stateful nature provides the functionality to detect a 417 dead or rebooted peer in a timely fashion. On the other hand, this 418 does not mean that the PAA-EP protocol itself needs to be stateful. 419 For example, an SNMP entity (i.e., an SNMP engine plus SNMP 420 applications) can generate SNMP queries on a particular MIB at an 421 interval short enough to perform peer liveness test and rebooted peer 422 detection. 424 Also, the peer liveness test and rebooted peer detection need to be 425 performed securely. 427 When SNMPv3 is used as the PAA-EP protocol, the SNMP management 428 framework supports snmpEngineBoots MIB [RFC3411]. By periodically 429 sending SNMP query to the peer to check the current value of this MIB 430 with the use of SNMP Security Subsystem, it is possible for an SNMP 431 entity to securely perform peer liveness test and rebooted peer 432 detection between PAA and EP. 434 5. Applicability of IPsec configuration MIBs 436 This section details the applicability of existing IPsec 437 configuration MIB modules to the EP configuration. These were found 438 to have general applicability and a fair level of re-usability for 439 the PANA EP configuration: 441 IPSec Security Policy Database (SPD) Configuration MIB: 443 [I-D.ietf-ipsp-spd-mib] defines a MIB module (IPSEC-SPD-MIB) for 444 configuration of an IPSec Security Policy Database (SPD). No 445 IPsec or IKE specific actions are defined within this document. 447 IPsec Security Policy IKE Action MIB: 449 [I-D.ietf-ipsp-ikeaction-mib] defines a MIB module (IPSEC- 450 IKEACTION-MIB) for configuration of an IKE action within the IPsec 451 SPD. 453 IPsec Security Policy IPsec Action MIB: 455 [I-D.ietf-ipsp-ipsecaction-mib] defines a MIB module (IPSEC- 456 IPSECACTION-MIB) for configuring IPsec actions within the IPsec 457 SPD. 459 The EP enforces binary authorization by filtering data traffic on the 460 basis of the Device Identifier (DI) of the PaC. The PAA must 461 provision its EPs with DI-based filters in order to control and 462 police the network access of a PaC. According to the definition of 463 the Device Identifier in [RFC4058], such filters - depending on the 464 access technology - might be either a IPv4/6 address or a link-layer 465 address of a connected device. 467 Do note also that a keying material might be provisioned. The 468 particular case where access control is performed using IPsec is 469 specified in [I-D.ietf-pana-ipsec]. The configuration aspects in 470 this case are detailed in Section 5.2. 472 5.1. General IP Access Control 474 The IPsec SPD MIB module (SPD-MIB) is designed to configure an IPsec 475 security policy database in a policy and rule oriented fashion. This 476 module is divided into 3 portions (Rules, Filters, Actions). 477 Specifically, SPD-MIB provides a generic mechanism for performing 478 packet processing based on a rule set. 480 The policy-based packet filtering and the corresponding execution of 481 actions is of a more general nature than for IPsec configuration 482 only, such as for configuration of a firewall. Rules within the 483 IPsec SPD-MIB are generic and simply bind a filter to an action. 484 Filters provided within the SPD-MIB itself are numerous and fairly 485 complete for most common packet filtering usage but externally 486 defined filters are supported. 488 For IPv4/v6 address-based filters provisioning, the DIFFSERV-MIB 489 module defined in [RFC3289] provides means to filter the traffic 490 based on the IP header information. DiffServ Multi-field Classifier 491 table provides such facilities: one can define the various tests that 492 are used when evaluating a given IP packet. The various tests 493 definable in this table are as follows: 495 o IP source address prefix, including host, CIDR Prefix, and "any 496 source address" 498 o IP destination address prefix, including host, CIDR Prefix, and 499 "any destination address" 501 o IPv6 Flow ID 503 o IP protocol or "any" 505 o TCP/UDP/SCTP source port range, including "any" 507 o TCP/UDP/SCTP destination port range, including "any" 509 o Differentiated Services Code Point 511 The results of each test are ANDed together to produce the result of 512 the entire filter. 514 The actions encapsulated within the SPD-MIB module are basic drop/ 515 accept actions. These are sufficient to perform EP binary 516 authorization enforcement at the EP. 518 When profile-based authorization information is provided to the EP, 519 more advanced actions like classifiers, meters and schedulers might 520 be configured by the PAA. This is out of the scope of the present 521 document. 523 5.2. Network Layer Secure Access Control (IPsec) 525 The PANA protocol authenticates the client and also establishes a 526 PANA security association between the PANA client and PANA 527 authentication agent at the end of successful authentication. The 528 PAA indicates the results of the authentication using the PANA-Bind- 529 Request (PBR) message wherein it can indicate the access control 530 method enforced by the access network and the IP address of the 531 corresponding EP. 533 When IPsec is used to perform access control, the PANA protocol 534 [I-D.ietf-pana-pana] does not discuss any details of IPsec [RFC2401] 535 SA establishment. Indeed, [I-D.ietf-pana-ipsec] discusses the 536 details for establishing IPsec security associations between the PaC 537 and the EP. When the IPsec SAs are successfully established, it can 538 be used to enforce access control and specifically used to prevent 539 the service theft mentioned in [RFC4016]. 541 In this particular context, one assumes that the following have 542 already happened before the IPsec SAs are established: 544 1. PANA client (PaC) and PAA mutually authenticate each other using 545 EAP methods that derive the AAA-Key [I-D.ietf-eap-keying]. 547 2. PaC learns the IP address of the Enforcement point (EP) during 548 the PANA exchange. 550 3. PaC learns that the network uses IPsec [RFC2401] for securing the 551 link between PaC and EP during the PANA exchange (PBR message). 553 4. PaC configures an IP address address before the PANA protocol 554 begins (the pre-PANA Address (PRPA), see [I-D.ietf-pana-pana]). 556 The IPsec IKE Action MIB module (IKEACTION-MIB) works within the 557 framework of the IPsec SPD-MIB. It can be referenced as an action by 558 the SPD-MIB and is used to configure IKE negotiations between network 559 devices. Hence, together with the SPD-MIB, the IKEACTION-MIB module 560 enables the PAA to configure IPSEC-based access control at the EP. 562 The PAA is then responsible to communicate to EP the following 563 information before IKE phase 1 exchange begins between PaC and EP: 565 The IKE pre-shared key: 567 To this end, the PAA must set a row in the IKE Credential Filter 568 table of the IKEACTION-MIB. This table defines filters, which can 569 be used to match credentials of IKE peers, where the credentials 570 in question have been obtained from an IKE phase 1 exchange. They 571 may be X.509 certificates, Kerberos tickets, or Pre-shared keys, 572 etc. 574 The PRPA of the PaC: 576 The DiffServ Multi-Field Classifier of the DIFFSERV-MIB is used 577 for configuring the SPD in a similar manner than what is described 578 in Section 5.1. 580 The Key-Id and PANA session ID: 582 [I-D.ietf-pana-ipsec] states that PaC and EP should use the PANA 583 session ID concatenated with the AAA-key as the value of the 584 ID_KEY_ID in aggressive mode for establishing the phase 1 SA. 585 Section 8 details usage examples that illustrate the way the 586 IKEACTION-MIB is used for this purpose. 588 6. PANA extension to the IPsec SPD MIB 590 Many existing MIB objects defined in the IPsec Configuration MIB 591 modules can be efficiently re-used for the PANA-specific needs. This 592 is detailed in Section 5. 594 The present section defines additional PANA-specific objects that 595 extend the IPsec SPD MIB module in order to entirely satisfy the 596 PAA-EP interface requirements. 598 6.1. Bootstrapping link layer ciphers 600 PANA can bootstrap not only network layer secure access control but 601 also any type of link layer secure access control. The following 602 parameters are defined to support bootstrapping link layer secure 603 access control: 605 panaL2FiltPmk: 607 A PMK (Pairwise Master Key) that is derived from AAA-Key and used 608 as the shared secret needed for executing a secure association 609 protocol between the PaC and EP in order to generate TSKs 610 (Transient Session Keys) [I-D.ietf-eap-keying]. In the case of 611 IEEE 802.11i [802.11i], an 802.11i PMK is carried in this MIB 612 object. 614 PMK Name: 616 The name fo the PMK. In the case of IEEE 802.11i, a 802.11i PMKID 617 is carried in this MIB object. 619 PMK Lifetime: 621 The lifetime of the PMK. The PMK must be invalidated when the PMK 622 lifetime expires. A new PMK with a new PMK lifetime may be 623 installed before the lifetime of the current PMK expires. The PMK 624 lifetime may be calculated from a RADIUS Session-Timeout attribute 625 or a Diameter Authorization-Lifetime AVP. 627 These parameters are contained in PanaL2FilterEntry together with 628 other link layer filtering parameters. 630 6.2. Notification of PaC presence 632 The SPD-MIB provides a means to notify to the SNMP manager (PAA) 633 information on packets matching/not matching the filters of given 634 rule. Such notification mechanisms and objects can be re-used for 635 notifying the PAA that unauthorized packets are trying to pass 636 through the EP. 638 If reliability needs to be guaranteed for the notifications 639 (panaNewPacIPNotification and panaNewPacL2Notification), hence Inform 640 notification (which is acknowledged) MUST be used. Then the PAA 641 needs to have engine-id to be the authoritative of SNMP clock between 642 EP and PAA (for inform operation the responder becomes the 643 authoritative). 645 6.3. PANA MIB Overview 647 Link-Layer filter table 649 [I-D.ietf-pana-pana] says the Device-Id AVP (code 1025) is of 650 Address Type [RFC3588]. The content for link-layer addresses is 651 expected to be specified in specific documents that describe how 652 IP operates over different link-layers. For instance, IPv6 over 653 Ethernet is described in [RFC2464]. To this end, additional 654 filters are designed in the present document. The link-layer 655 filter test the L2 address (e.g. MAC address, port, DSL line) and 656 also defines a set of parameters needed for bootstrapping link- 657 layer ciphering, including a PMK (Pair-wise Master Key), the PMK 658 name and the PMK lifetime. Note that the definition of this table 659 does not assume the usage of any particular link-layer. 661 When the MIB module definition for a particular link-layer defines 662 MIB objects for the parameters specific to that link-layer, the 663 link-layer specific parameters SHOULD be accessed via the PANA MIB 664 using the link-layer filter table, instead of accessing them via 665 the link-layer specific MIB. 667 New PaC notification tables 669 These tables define new notifications, which aims at satisfying 670 this requirement. It re-uses existing notification variable 671 objects pre-defined in the SPD-MIB. 673 The "New PaC" notifications (panaNewPacIPNotification and 674 panaNewPaCL2Notification) are triggered when the EP detects 675 traffic coming from an unauthorized source. 677 If the traffic detected is an IP flow, the objects sent must 678 include spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, 679 and spdIPDestinationAddress objects to indicate the packet source 680 and destination of the packet that triggered the action. 681 Additionally, the spdIPInterfaceType and spdIPInterfaceAddress 682 objects are included to indicate which interface the action was 683 executed in association with and if the packet was inbound or 684 outbound through the endpoint. See [I-D.ietf-ipsp-spd-mib] for 685 further details. 687 If the traffic detected is Link-layer traffic, the objects sent 688 must include the index of the interface which detected such 689 traffic and potentially the L2 address source of the traffic. 691 6.4. PANA MIB Objects Definition 693 PANA-EP-MIB DEFINITIONS ::= BEGIN 695 IMPORTS 697 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE 698 FROM SNMPv2-SMI 700 TEXTUAL-CONVENTION, RowStatus, PhysAddress, StorageType, 701 TimeStamp, TimeInterval 702 FROM SNMPv2-TC 704 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 705 FROM SNMPv2-CONF 707 InterfaceIndex 708 FROM IF-MIB 710 spdMIB, spdIPEndpointAddType, spdIPEndpointAddress, 711 spdActionExecuted, spdIPSourceType, spdIPSourceAddress, 712 spdIPDestinationType,spdIPDestinationAddress 713 FROM IPSEC-SPD-MIB; 715 -- 716 -- Module identity 717 -- 719 panaMIB MODULE-IDENTITY 720 LAST-UPDATED 721 "200512220000Z" -- 22 december 2004 722 ORGANIZATION 723 "IETF PANA Working Group" 724 CONTACT-INFO 725 "Yacine El Mghazli 726 Alcatel 727 Route de Nozay 728 91460 Marcoussis 729 France 730 Email: yacine.el_mghazli@alcatel.fr 732 Yoshihiro Ohba 733 Toshiba America Research, Inc. 734 1, Telcordia Drive 735 Piscataway, NJ 08854 736 USA 737 Email: yohba@tari.toshiba.com" 738 DESCRIPTION 739 "The MIB module for defining additional PANA-specific objects to 740 the IPsec SPD MIB. Copyright (C) The Internet Society (2003). 741 This version of this MIB module is part of RFC XXXX, see the 742 RFC itself for full legal notices." 744 -- Revision History 745 REVISION 746 "200506280000Z" -- 22 december 2005 747 DESCRIPTION 748 "L2 Filter indexing modified" 749 REVISION 750 "200506280000Z" -- 28 Juin 2005 751 DESCRIPTION 752 "L2 protection generic parameters" 753 REVISION 754 "200502050000Z" -- 05 February 2005 755 DESCRIPTION 756 "L2 generic filters" 757 REVISION 758 "200410220000Z" -- 22 October 2004 759 DESCRIPTION 760 "Version 02, draft-ietf-pana-snmp-02.txt" 761 REVISION 762 "200402050000Z" -- 05 February 2004 763 DESCRIPTION 764 "Version 01, draft-yacine-pana-paa2ep-snmp-01.txt" 765 REVISION 766 "200310310000Z" -- 31 October 2003 767 DESCRIPTION 768 "Initial version, draft-yacine-pana-paa2ep-snmp-00.txt" 769 ::= { spdMIB XXX } -- XXX to be assigned by IANA 771 -- 772 -- groups of related objects 773 -- 775 panaConfigObjects OBJECT IDENTIFIER 776 ::= { panaMIB 1 } 777 panaNotificationObjects OBJECT IDENTIFIER 778 ::= { panaMIB 2} 779 panaConformanceObjects OBJECT IDENTIFIER 780 ::= { panaMIB 3 } 782 -- 783 -- Textual Conventions 784 -- 786 PanaKey ::= TEXTUAL-CONVENTION 787 STATUS current 788 DESCRIPTION 789 "The PanaKey is used to carry a key. When the key does 790 not exist, the length of the key becomes zero." 791 SYNTAX OCTET STRING (SIZE(0..255)) 793 PanaKeyName ::= TEXTUAL-CONVENTION 794 STATUS current 795 DESCRIPTION 796 "The PanaKeyName is used to carry the name of a PanaKey. 797 When the key name does not exist, the length of the 798 key name becomes zero." 799 SYNTAX OCTET STRING (SIZE(0..255)) 801 -- 802 -- PANA Additional Filters Objects 803 -- 805 -- 806 -- The Link-layer Filter Table 807 -- 809 panaL2FilterTable OBJECT-TYPE 810 SYNTAX SEQUENCE OF PanaL2FilterEntry 811 MAX-ACCESS not-accessible 812 STATUS current 813 DESCRIPTION 814 "Link-layer filter definitions." 815 ::= { panaConfigObjects 1 } 817 panaL2FilterEntry OBJECT-TYPE 818 SYNTAX PanaL2FilterEntry 819 MAX-ACCESS not-accessible 820 STATUS current 821 DESCRIPTION 822 "An entry in the Link-layer filter table." 823 INDEX { panaL2FiltEpIfIndex, panaL2FiltAddr } 824 ::= { panaL2FilterTable 1 } 826 PanaL2FilterEntry ::= SEQUENCE { 827 panaL2FiltEpIfIndex InterfaceIndex, 828 panaL2FiltAddr PhysAddress, 829 panaL2FiltPmk PanaKey, 830 panaL2FiltPmkName PanaKeyName, 831 panaL2FiltPmkLifetime TimeInterval, 832 panaL2FiltLastChanged TimeStamp, 833 panaL2FiltStorageType StorageType, 834 panaL2FiltRowStatus RowStatus 835 } 837 panaL2FiltEpIfIndex OBJECT-TYPE 838 SYNTAX InterfaceIndex 839 MAX-ACCESS read-create 840 STATUS current 841 DESCRIPTION 842 "The index identifying the EP interface where the filter 843 policy must be enforced on." 844 ::= { panaL2FilterEntry 1 } 846 panaL2FiltAddr OBJECT-TYPE 847 SYNTAX PhysAddress 848 MAX-ACCESS read-create 849 STATUS current 850 DESCRIPTION 851 "The authorized device Link-layer address (DI). For 852 example, for a 802.x interface, this object normally 853 contains a MAC address. For interfaces which do not have such 854 an address (e.g., a serial line), this object should contain 855 an octet string of zero length." 856 ::= { panaL2FilterEntry 2 } 858 panaL2FiltPmk OBJECT-TYPE 859 SYNTAX PanaKey 860 MAX-ACCESS read-create 861 STATUS current 862 DESCRIPTION 863 "This is PMK (Pairwise Master Key) used for bootstraping 864 link-layer ciphers." 865 ::= { panaL2FilterEntry 3 } 866 panaL2FiltPmkName OBJECT-TYPE 867 SYNTAX PanaKeyName 868 MAX-ACCESS read-create 869 STATUS current 870 DESCRIPTION 871 "This is the name of the panaL2Pmk." 872 ::= { panaL2FilterEntry 4 } 874 panaL2FiltPmkLifetime OBJECT-TYPE 875 SYNTAX TimeInterval 876 MAX-ACCESS read-create 877 STATUS current 878 DESCRIPTION 879 "This is the lifetime of panaL2Pmk." 880 ::= { panaL2FilterEntry 5 } 882 panaL2FiltLastChanged OBJECT-TYPE 883 SYNTAX TimeStamp 884 MAX-ACCESS read-only 885 STATUS current 886 DESCRIPTION 887 "The value of sysUpTime when this row was last modified or 888 created either through SNMP SETs or by some other external 889 means." 890 ::= { panaL2FilterEntry 6 } 892 panaL2FiltStorageType OBJECT-TYPE 893 SYNTAX StorageType 894 MAX-ACCESS read-create 895 STATUS current 896 DESCRIPTION 897 "The storage type for this row. Rows in this table which were 898 created through an external process may have a storage type 899 of readOnly or permanent." 900 DEFVAL { nonVolatile } 901 ::= { panaL2FilterEntry 7 } 903 panaL2FiltRowStatus OBJECT-TYPE 904 SYNTAX RowStatus 905 MAX-ACCESS read-create 906 STATUS current 907 DESCRIPTION 908 "This object indicates the conceptual status of this row." 909 ::= { panaL2FilterEntry 8 } 910 -- 911 -- 912 -- Notification objects information 913 -- 914 -- 916 panaNotificationVariables OBJECT IDENTIFIER ::= 917 { panaNotificationObjects 1 } 919 panaNotifications OBJECT IDENTIFIER ::= 921 { panaNotificationObjects 0 } 923 panaEpIfIndex OBJECT-TYPE 924 SYNTAX InterfaceIndex 925 MAX-ACCESS accessible-for-notify 926 STATUS current 927 DESCRIPTION 928 "Contains the interface index on which the packet triggered 929 the notification in question." 930 ::= { panaNotificationVariables 1 } 932 panaL2SourceAddress OBJECT-TYPE 933 SYNTAX PhysAddress 934 MAX-ACCESS accessible-for-notify 935 STATUS current 936 DESCRIPTION 937 "Contains the source Link layer address of the packet which 938 triggered the notification in question. For 939 example, for a 802.x frame, this object normally 940 contains a MAC address. For interfaces which do not have such 941 an address (e.g., a serial line), this object should contain 942 an octet string of zero length. " 943 ::= { panaNotificationVariables 2 } 945 panaNewPacIPNotification NOTIFICATION-TYPE 946 OBJECTS { 947 spdActionExecuted, 948 spdIPEndpointAddType, 949 spdIPEndpointAddress, 950 spdIPSourceType, 951 spdIPSourceAddress, 952 spdIPDestinationType, 953 spdIPDestinationAddress} 954 STATUS current 955 DESCRIPTION 956 "Notification that EP detected IP traffic coming from an 957 unauthorized source." 958 ::= { panaNotifications 1 } 960 panaNewPacL2Notification NOTIFICATION-TYPE 961 OBJECTS { 962 spdActionExecuted, 963 panaEpIfIndex, 964 panaL2SourceAddress 965 } 966 STATUS current 968 DESCRIPTION 969 "Notification that EP detected L2 traffic coming from an 970 unauthorized source. " 971 ::= { panaNotifications 2 } 973 -- 974 -- 975 -- Conformance information 976 -- 977 -- 979 panaGroups OBJECT IDENTIFIER 980 ::= { panaConformanceObjects 1 } 981 panaCompliances OBJECT IDENTIFIER 982 ::= { panaConformanceObjects 2 } 984 -- 985 -- Compliance Groups Definitions 986 -- 988 panaL2FilterGroup OBJECT-GROUP 989 OBJECTS { 990 panaL2FiltEpIfIndex, 991 panaL2FiltAddr, 992 panaL2FiltPmk, 993 panaL2FiltPmkName, 994 panaL2FiltPmkLifetime, 995 panaL2FiltLastChanged, 996 panaL2FiltStorageType, 997 panaL2FiltRowStatus } 998 STATUS current 999 DESCRIPTION 1000 "The Link-layer Filter Group." 1001 ::= { panaGroups 1 } 1003 panaNewPacL2NotificationObjectsGroup OBJECT-GROUP 1004 OBJECTS { 1005 panaEpIfIndex, 1006 panaL2SourceAddress} 1007 STATUS current 1008 DESCRIPTION 1009 "PaC Presence Notification Objects Group." 1010 ::= { panaGroups 2 } 1012 panaNewPacNotificationGroup NOTIFICATION-GROUP 1013 NOTIFICATIONS { 1014 panaNewPacIPNotification, 1015 panaNewPacL2Notification} 1016 STATUS current 1017 DESCRIPTION 1018 "PaC Presence Notification Group." 1019 ::= { panaGroups 3 } 1021 -- 1022 -- Compliance statements 1023 -- 1025 panaFilterCompliance MODULE-COMPLIANCE 1026 STATUS current 1027 DESCRIPTION 1028 "The compliance statement for SNMP entities that support 1029 PANA DI-based filtering." 1031 MODULE -- This Module 1033 MANDATORY-GROUPS { panaL2FilterGroup } 1035 OBJECT panaL2FiltRowStatus 1036 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1037 DESCRIPTION 1038 "Support of the values notInService(2), notReady(3), 1039 and createAndWait(5) is not required." 1041 OBJECT panaL2FiltLastChanged 1042 MIN-ACCESS not-accessible 1043 DESCRIPTION 1044 "This object not required for compliance." 1045 MODULE IPSEC-SPD-MIB 1047 MANDATORY-GROUPS { 1048 spdEndpointGroup, 1049 spdGroupContentsGroup, 1050 spdRuleDefinitionGroup, 1051 spdStaticFilterGroup, 1052 spdStaticActionGroup } 1054 OBJECT spdEndGroupRowStatus 1055 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1056 DESCRIPTION 1057 "Support of the values notInService(2), notReady(3), 1058 and createAndWait(5) is not required." 1060 OBJECT spdEndGroupLastChanged 1061 MIN-ACCESS not-accessible 1062 DESCRIPTION 1063 "This object not required for compliance." 1065 OBJECT spdGroupContComponentType 1066 SYNTAX INTEGER { rule(2) } 1067 DESCRIPTION 1068 "Support of the value group(1) is only required for 1069 implementations which support Policy Groups within 1070 Policy Groups." 1072 OBJECT spdGroupContRowStatus 1073 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1074 DESCRIPTION 1075 "Support of the values notInService(2), notReady(3), 1076 and createAndWait(5) is not required." 1078 OBJECT spdGroupContLastChanged 1079 MIN-ACCESS not-accessible 1080 DESCRIPTION 1081 "This object not required for compliance." 1083 OBJECT spdRuleDefRowStatus 1084 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1085 DESCRIPTION 1086 "Support of the values notInService(2), notReady(3), 1087 and createAndWait(5) is not required." 1089 OBJECT spdRuleDefLastChanged 1090 MIN-ACCESS not-accessible 1091 DESCRIPTION 1092 "This object not required for compliance." 1093 ::= { panaCompliances 1 } 1095 panaNewPacNotificationCompliance MODULE-COMPLIANCE 1096 STATUS current 1097 DESCRIPTION 1098 "The compliance statement for SNMP entities that support 1099 new PaC presence Notification." 1101 MODULE -- This Module 1103 MANDATORY-GROUPS { 1104 panaNewPacL2NotificationObjectsGroup, 1105 panaNewPacNotificationGroup 1106 } 1108 MODULE IPSEC-SPD-MIB 1110 MANDATORY-GROUPS { spdActionLoggingObjectGroup } 1112 ::= { panaCompliances 2 } 1114 END 1116 7. Applicability of RTFM Meter MIB 1118 RTFM provides for the measurement of network traffic flows: 1120 o a method of specifying traffic flows within a network 1122 o a hierarchy of devices (meters, meter readers, managers) for 1123 measuring the specified flows 1125 o a mechanism for configuring meters and meter readers, and for 1126 collecting the flow data from remote meters 1128 RTFM provides high time resolution for flow first- and last-packet 1129 times. Counters for long-duration flows may be read at intervals 1130 determined by a manager. The RTFM Meter is designed so as to do as 1131 much data reduction work as possible, which minimizes the amount of 1132 data to be read and the amount of processing needed to produce useful 1133 reports from it. 1135 RTFM flow data can be used for a wide range of purposes, such as 1136 usage accounting, long-term recording of network usage (classified by 1137 IP address attributes) and real-time analysis of traffic flows at 1138 remote metering points. 1140 PANA recommends the use of the following RTFM module and architecture 1141 for the PAA to collect accounting information from the EP(s). It is 1142 the responsability of the PAA to organise the correlation between the 1143 EP filters, RTFM flows, the PANA and the AAA sessions. 1145 RTFM Meter MIB [RFC2720] describes the SNMP Management Information 1146 Base for an RTFM meter, including its flow table, rule table (storing 1147 the meter's rulesets) and the control tables used for managing a 1148 meter and reading flow data from it. 1150 [RFC2722] defines the RTFM Architecture, giving descriptions of each 1151 component. Explains how traffic flows are viewed as logical entities 1152 described in terms of their address-attribute values, so that each is 1153 defined by the attributes of its end-points. Gives a detailed 1154 description of the RTFM traffic meter, with full details of how flows 1155 are stored in the meter's flow table, and how packets are matched in 1156 accordance with rules stored in a ruleset. 1158 8. EP Configuration Example 1160 Below are usage examples of the MIB modules in the PANA context. 1162 8.1. Common setup 1164 The "EndPoint to Group" table is used to map policy (groupings) onto 1165 an endpoint (EP-ADDR is the IP address) where traffic is to pass by. 1166 Any policy group assigned to an endpoint is then used to control 1167 access to the traffic passing by it. 1169 So far, we define below two policy groups at the EP interface ("EP- 1170 SPD-IN" and "EP-SPD-OUT"). 1172 spdEndpointToGroupTable, row 1: 1174 o spdEndGroupDirection = incoming; 1176 o spdEndGroupIdentType = IPv4; 1178 o spdEndGroupAddress = EP-ADDR; 1180 o spdEndGroupName = "EP-SPD-IN"; 1182 spdEndpointToGroupTable, row 2: 1184 o spdEndGroupDirection = outgoing; 1186 o spdEndGroupIdentType = IPv4; 1188 o spdEndGroupAddress = EP-ADDR; 1190 o spdEndGroupName = "EP-SPD-OUT"; 1192 Within each of the policy group defined above, we define a sub-group 1193 (a compound filter) dedicated to the treatment of traffic that is 1194 allowed prior to any configuration. The following configuration 1195 illustrates the incoming allowed unprotected traffic: 1197 spdGroupContentsTable, row 1: 1199 o spdGroupContName = "EP-SPD-IN"; 1201 o spdGroupContPriority = '10'; 1203 o spdGroupContFilter = spdTrueFilterInstance; 1204 o spdGroupContComponentType = group; 1206 o spdGroupContComponentName = "EP-ALLOWED-UNPROTECTED-IN"; 1208 Within this sub-group, we define a rule (a sub-filter) dedicated to 1209 each allowed traffic types (namely PANA, ARP, IPv6 Neighbor 1210 Discovery, DHCP, etc). The following configuration illustrates the 1211 case of incoming DHCP traffic: 1213 spdGroupContentsTable, row 2: 1215 o spdGroupContName = "EP-ALLOWED-UNPROTECTED-IN"; 1217 o spdGroupContPriority = '1'; 1219 o spdGroupContFilter = diffServMultiFieldClfrTable.10; 1221 o spdGroupContComponentType = rule; 1223 o spdGroupContComponentName = "EP-DHCP-ACCEPT-IN"; 1225 We define the corresponding filter in the DiffServ Multi-Field 1226 Classifier table (DIFFSERV_MIB, [RFC3289]), which matches the DHCP 1227 packets: 1229 diffServMultiFieldClfrTable, row 10: 1231 o diffServMultiFieldClfrAddrType = v4; 1233 o diffServMultiFieldClfrSrcL4PortMin = '546' (DHCP); 1235 o diffServMultiFieldClfrSrcL4PortMax = '547' (DHCP); 1237 o diffServMultiFieldClfrProtocol = '17' (UDP); 1239 The "Rule Defininition" table links a rule with a given action in the 1240 SPD action MIB. E.g. the following entries links the filter defined 1241 above with the "accept" action statically defined in the SPD MIB 1242 (spdStaticActions.3). 1244 spdRuleDefinitionTable, row 1: 1246 o spdRuleDefName = "EP-DHCP-ACCEPT-IN"; 1248 o spdRuleDefDescription = "Allow Incoming DHCP packets"; 1250 o spdRuleDefFilter = spdTrueFilterInstance; 1251 o spdRuleDefFilterNegated = false (default); 1253 o spdRuleDefAction = spdAcceptAction; 1255 8.2. General IP-based Access Control 1257 In this section, we need to configure the SPD so that EP accepts IP 1258 packets coming from/going to the client 'PaC1'. In the whole 1259 section, 'PaC1-IP@' is the IP address of 'PaC1'. 1261 Within the incoming policy group defined above ("EP-SPD-IN"), we 1262 define a rule dedicated to the treatment of packets coming from 1263 "PaC1" and the EP we are provisioning. 1265 spdGroupContentsTable, row 3: 1267 o spdGroupContName = "EP-SPD-IN"; 1269 o spdGroupContPriority = '100'; 1271 o spdGroupContFilter = diffServMultiFieldClfrTable.1; 1273 o spdGroupContComponentType = rule; 1275 o spdGroupContComponentName = "EP-PaC1-ACCEPT-IN"; 1277 We define the filter in the DiffServ Multi-field Classifier table, 1278 which matches IP packets coming from the PaC: 1280 diffServMultiFieldClfrTable, row 1: 1282 o diffServMultiFieldClfrAddrType = v4; 1284 o diffServMultiFieldClfrSrcAddr = 'PaC1-IP@'; 1286 diffServMultiFieldClfrTable, row 2: 1288 o diffServMultiFieldClfrAddrType = v4; 1290 o diffServMultiFieldClfrDstAddr = 'PaC1-IP@'; 1292 The following entries links the two filters defined above with the 1293 "accept" action. 1295 spdRuleDefinitionTable, row 2: 1297 o spdRuleDefName = "EP-PaC1-ACCEPT-IN"; 1298 o spdRuleDefDescription = "Allow Incoming IP packets from PaC1"; 1300 o spdRuleDefFilter = spdTrueFilterInstance; 1302 o spdRuleDefFilterNegated = false (default); 1304 o spdRuleDefAction = spdAcceptAction; 1306 spdRuleDefinitionTable, row 3: 1308 o spdRuleDefName = "EP-PaC1-ACCEPT-OUT"; 1310 o spdRuleDefDescription = "Allow Outgoing IP packets to PaC1"; 1312 o spdRuleDefFilter = spdTrueFilterInstance; 1314 o spdRuleDefFilterNegated = false (default); 1316 o spdRuleDefAction = spdAcceptAction; 1318 The same thing must be done for the outgoing direction and this 1319 results in a policy such that any packet coming from/going to the PaC 1320 is allowed to go through the EP (via EP-ADDR endpoint). 1322 8.3. IPsec-based Access Control 1324 In this section we consider the case when IPsec is used to control 1325 access at the IP level. In order to avoid many redundancies, the 1326 previous configuration set is still valid. See below a usage example 1327 of IKEACTION-MIB and IPSECACTION-MIB. 1329 -- IKE Phase 1 configuration (agressive mode): 1331 We define a first-level filter in policy group "EP-SPD-IN" of the SPD 1332 MIB, using the "Group contents" table. This filter isolates IKE 1333 phase 1 traffic coming to the EP on this interface: 1335 spdGroupContentsTable, row 4: 1337 o spdGroupContName = "EP-SPD-IN"; 1339 o spdGroupContPriority = '1'; 1341 o spdGroupContFilter = ipiaIkePhase1Filter; 1343 o spdGroupContComponentType = group; 1344 o spdGroupContComponentName = "EP-IKE1-IN"; 1346 Within this IKE-specific policy sub-group, we specify a second-level 1347 filter to apply for for the traffic coming from PaC1. 1349 spdGroupContentsTable, row 5: 1351 o spdGroupContName = "EP-IKE-Phase1-IN"; 1353 o spdGroupContPriority = '1'; 1355 o spdGroupContFilter = diffServMultiFieldClfrTable.1; 1357 o spdGroupContComponentType = group; 1359 o spdGroupContComponentName = "EP-IKE1-PaC1-IN"; 1361 The diffServMultiFieldClfrTable.1 entry has been defined in the 1362 previous section. Within the lattest sub-group we finally specify 1363 the rule to apply for the IKE traffic coming from PaC1 and matching 1364 the right identity (id_key_id). 1366 spdGroupContentsTable, row 6: 1368 o spdGroupContName = "EP-IKE1-PaC1-IN"; 1370 o spdGroupContPriority = '1'; 1372 o spdGroupContFilter = ipiaPeerIdentityFilterTable.1; 1374 o spdGroupContComponentType = rule; 1376 o spdGroupContComponentName = "PaC1-IKE1-RULE"; 1378 The "Peer Identity Filter" table specifically informs the EP on the 1379 value of the idKeyId to use in IKE messages: 1381 ipiaPeerIdentityFilterTable, row 1: 1383 o ipiaPeerIdFiltName = "PaC1-IKE1-ID-FILTER"; 1385 o ipiaPeerIdFiltIdentityType = id_Key_Id; 1387 o ipiaPeerIdFiltIdentityValue = 'PANA-Session-Id|PANA-Key-Id'; 1389 The "Rule Defininition" table links a rule with a given action in the 1390 IKE action MIB. This action will be triggered upon reception at the 1391 EP of an IKE phase 1 packet coming from PaC1 and matching the right 1392 id_key_id. 1394 spdRuleDefinitionTable, row 4: 1396 o spdRuleDefName = "PaC1-IKE-RULE"; 1398 o spdRuleDefDescription = "IPsec Access Control for PaC1"; 1400 o spdRuleDefFilter = spdTrueFilterInstance; 1402 o spdRuleDefFilterNegated = false (default); 1404 o spdRuleDefAction = ipiaIkeActionTable.1; 1406 The spdRuleDefAction attribute in the entry above points to a row in 1407 the ipiaIkeActionTable, defined below: 1409 ipiaIkeActionTable, row 1: 1411 o ipiaIkeActName = "PaC1-IKE"; 1413 o ipiaIkeActParametersName = "SA1-PaC1"; 1415 o ipiaIkeActThresholdDerivedKeys = '100' (default); 1417 o ipiaIkeActExchangeMode = aggressive; 1419 o ipiaIkeActAgressiveModeGroupId = 'xxx' (Diffie-Hellman values); 1421 o ipiaIkeActIdentityType = id_Key_Id; 1423 o ipiaIkeActIdentityContext = "PANA"; 1425 o ipiaIkeActPeerName = "PaC1"; 1427 The following entry links together the "PaC1" identity with the 1428 corresponding credentials table entry: 1430 ipiaIkeIdentityTable, row 1: 1432 o spdEndGroupIdentType = IPv4; 1434 o spdEndGroupAddress = 'EP-ADDR'; 1436 o ipiaIkeActIdentityType = id_Key_Id; 1438 o ipiaIkeActIdentityContext = 'PANA'; 1439 o ipiaIkeIdCredentialName = "PaC1-PSK"; 1441 Finally, the pre-shared key derivated at the PAA is set in the IPSA 1442 Credentials table (IPSECACTION-MIB): 1444 ipsaCredentialTable, row 1: 1446 o ipsaCredName = "PaC1-PSK"; 1448 o ipsaCredType = sharedSecret; 1450 o ipsaCredCredential = 'PSK-derived-at-the-PAA'; 1452 o ipsaCredSize = 'xxx'; 1454 o ipsaMgnName = "xxx"; 1456 o ipsaRemoteID = 'PaC1'; 1458 The Ike Action entry (above) is indexed by a name (ipiaIkeActName 1459 attribute), which is used as the primary index into the 1460 ipiaIkeActionProposalsTable. The secondary index is a priority, 1461 which allows ordering of the proposals that will be sent to the peer 1462 (or accepted from the peer). 1464 ipiaIkeActionProposalsTable, row 1: 1466 o ipiaIkeActPropName = "PaC1-IKE-PROP1"; 1468 o ipiaIkeActPropPriority = '1'; 1470 The ipiaIkeActPropName points to a row in the ipiaIkeProposalsTable, 1471 which contains the actual IKE parameters for the Phase 1 exchanges: 1473 ipiaIkeProposalsTable, row 1: 1475 o ipiaIkeActPropName = "PaC1-IKE-PROP1"; 1477 o ipiaIkePropLifetimeDerivedKeys = xxx; 1479 o ipiaIkePropCipherAlgorithm = 3DES; 1481 o ipiaIkePropCipherKeyLength = xxx; 1483 o ipiaIkePropHashAlgorithm = HMAC-SHA1; 1485 o ipiaIkePropPrfAlgorithm = xxx; 1486 o ipiaIkePropVendorId = xxx; 1488 o ipiaIkePropDhGroup = 2; 1490 o ipiaIkePropAuthenticationMethod = xxx; 1492 o ipiaIkePropMaxLifetimeSecs = xxx; 1494 o ipiaIkePropMaxLifetimeKB = xxx; 1496 There is a similar hierarchy for the proposals, which are used for 1497 Phase 2 negotiations, and result in a Phase 2 SA being created, upon 1498 successful negotiations. The parameters would be set up in the 1499 ipiaIpsecActionTable, ipiaIpsecProposalsTable and 1500 ipiaIpsecTransformsTable, along with the necessary related tables. 1501 One would then need a rule to trigger the row in the 1502 ipiaIpsecActionTable. See for further details on the IPSP MIBs 1503 usage. 1505 8.4. Link-layer Access control 1507 The section below gives a usage example of the PANA module in the 1508 general L2-based access control case. 1510 The example below assumes the configuration set detailed in 1511 Section 8.1 is valid. Here we need to configure the SPD so that EP 1512 accepts accepts 802 packets coming from/going to the client 'PaC1'? 1513 In the whole section 'PaC1-MAC@' is the MAC address of 'PaC1'. 1515 Within the incoming policy group defined above ("EP-SPD-IN"), we 1516 define a rule dedicated to the treatment of packets coming from 1517 "PaC1" and the EP we are provisioning. 1519 spdGroupContentsTable, row 3: 1521 o spdGroupContName = "EP-SPD-IN"; 1523 o spdGroupContPriority = '101'; 1525 o spdGroupContFilter = panaL2FilterTable.1; 1527 o spdGroupContComponentType = rule; 1529 o spdGroupContComponentName = "EP-PaC1-ACCEPT-IN-L2"; 1531 We define the filter in the Link-layer filter table, which matches L2 1532 packets coming from the PaC to interface #5, which a 802.11 1533 interface: 1535 panaL2FilterTable, row 1: 1537 o panaL2FiltEpIfIndex = 5; 1539 o panaL2FiltAddr = "00-11-0A-80-4A-58"; 1541 o panaL2FiltPmk = "..."; 1543 o panaL2FiltPmkName = "..."; 1545 o panaL2FiltPmkLifetime = 10800; 1547 The following entries links the filter defined above with the 1548 "accept" action. 1550 spdRuleDefinitionTable, row 20: 1552 o spdRuleDefName = "EP-PaC1-ACCEPT-IN-L2"; 1554 o spdRuleDefDescription = "Allow Incoming L2 packets from PaC1 via 1555 Interface #5"; 1557 o spdRuleDefFilter = spdTrueFilterInstance; 1559 o spdRuleDefFilterNegated = false (default); 1561 o spdRuleDefAction = spdAcceptAction; 1563 The same thing must be done for the outgoing direction and this 1564 results in a policy such that any packet coming from/going to the PaC 1565 is allowed to go through the EP. 1567 9. Security Considerations 1569 The MIB defined in the present document relates to a system which 1570 will provide network access. As such, improper manipulation of the 1571 objects represented by this MIB may result in denial of service to a 1572 large number of end-users. In addition, manipulation of the 1573 panaL2FilterTable and diffServMultiFieldClfrTable may allow an end- 1574 user to gain network access, spoof their IP addresses, change the 1575 authorized device identifiers, or affect other end-users in either a 1576 positive or negative manner. 1578 There are a number of management objects defined in this MIB module 1579 with a MAX-ACCESS clause of read-write and/or read-create. Such 1580 objects may be considered sensitive or vulnerable in some network 1581 environments. The support for SET operations in a non-secure 1582 environment without proper protection can have a negative effect on 1583 network operations. These are the tables and objects and their 1584 sensitivity/vulnerability: 1586 o The use of panaL2FilterTable to specify which Link-layer addresses 1587 are authorized to access the network on which interface is 1588 considered to be only limited protection and does not protect 1589 against attacks which spoof the management station's IP address. 1590 The use of SNMPv3 security is mandated. Specifically, SNMPv3 VACM 1591 and USM MUST be used with any v3 agent which implements this MIB. 1593 As described in Section 2.1, it is assumed that PAA and EP are pre- 1594 configured to be able to communicate each other with a required 1595 security association. The pre-configured SNMP user passphrase for 1596 the security association between PAA and EP should not be used for a 1597 long term and should be updated at a reasonable frequency. 1599 It might be sufficient to use the same SNMP user identity and 1600 passphrase for all EPs controlled by the same PAA (the same thing can 1601 apply even when the EPs are controlled by multiple PAAs.) Note that 1602 even if the same SNMP user identity and passphrase for all EPs are 1603 used, the different SNMP authentication and encryption keys are 1604 derived for each EP, because the combination of SNMP user identity 1605 and engine-id is used for deriving the keys. 1607 SNMP versions prior to SNMPv3 did not include adequate security. 1608 Even if the network itself is secure (for example by using IPsec), 1609 even then, there is no control as to who on the secure network is 1610 allowed to access and GET/SET (read/change/create/delete) the objects 1611 in this MIB module. 1613 It is RECOMMENDED that implementers consider the security features as 1614 provided by the SNMPv3 framework (see [RFC3410], section 8), 1615 including full support for the SNMPv3 cryptographic mechanisms (for 1616 authentication and privacy). 1618 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1619 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1620 enable cryptographic security. It is then a customer/operator 1621 responsibility to ensure that the SNMP entity giving access to an 1622 instance of this MIB module is properly configured to give access to 1623 the objects only to those principals (users) that have legitimate 1624 rights to indeed GET or SET (change/create/delete) them. 1626 10. IANA Considerations 1628 The only IANA considerations for this document is the node number 1629 allocation of the PANA-EP-MIB itself. 1631 11. Acknowledgements 1633 The authors would like to thank David Perkins for the MIB deep 1634 inspection and Robert Story, who provided very helpful 1635 recommendations on the IPSP MIBs usage. 1637 This document originaly leverages on similar works done in the MIDCOM 1638 working group. Thanks to the authors of those IDs. Thanks to Thomas 1639 Moore and Olivier Marce for their grateful help during the edition of 1640 this document. 1642 12. References 1644 12.1. Normative References 1646 [I-D.ietf-pana-pana] 1647 Forsberg, D., "Protocol for Carrying Authentication for 1648 Network Access (PANA)", draft-ietf-pana-pana-10 (work in 1649 progress), July 2005. 1651 [I-D.ietf-pana-ipsec] 1652 Parthasarathy, M., "PANA Enabling IPsec based Access 1653 Control", draft-ietf-pana-ipsec-07 (work in progress), 1654 July 2005. 1656 [I-D.ietf-ipsp-spd-mib] 1657 Hardaker, W., "IPsec Security Policy Database 1658 Configuration MIB", draft-ietf-ipsp-spd-mib-03 (work in 1659 progress), October 2005. 1661 [I-D.ietf-ipsp-ikeaction-mib] 1662 Hardaker, W., "IPsec Security Policy IKE Action MIB", 1663 draft-ietf-ipsp-ikeaction-mib-01 (work in progress), 1664 August 2005. 1666 [I-D.ietf-ipsp-ipsecaction-mib] 1667 Hardaker, W., "IPsec Security Policy IPsec Action MIB", 1668 draft-ietf-ipsp-ipsecaction-mib-01 (work in progress), 1669 August 2005. 1671 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1672 Schoenwaelder, Ed., "Structure of Management Information 1673 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1675 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1676 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1677 STD 58, RFC 2579, April 1999. 1679 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1680 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1681 April 1999. 1683 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 1684 Base for the Differentiated Services Architecture", 1685 RFC 3289, May 2002. 1687 12.2. Informative References 1689 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1690 "Protocol for Carrying Authentication for Network Access 1691 (PANA) Requirements", RFC 4058, May 2005. 1693 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1694 and Network Access (PANA) Threat Analysis and Security 1695 Requirements", RFC 4016, March 2005. 1697 [I-D.ietf-pana-framework] 1698 Jayaraman, P., "PANA Framework", 1699 draft-ietf-pana-framework-05 (work in progress), 1700 July 2005. 1702 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1703 (USM) for version 3 of the Simple Network Management 1704 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1706 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1707 "Introduction and Applicability Statements for Internet- 1708 Standard Management Framework", RFC 3410, December 2002. 1710 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 1711 Architecture for Describing Simple Network Management 1712 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1713 December 2002. 1715 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1716 Internet Protocol", RFC 2401, November 1998. 1718 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1719 (IKE)", RFC 2409, November 1998. 1721 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1722 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1724 [I-D.ietf-aaa-diameter-cc] 1725 Mattila, L., Koskinen, J., Stura, M., Loughney, J., and H. 1726 Hakala, "Diameter Credit-control Application", 1727 draft-ietf-aaa-diameter-cc-06 (work in progress), 1728 August 2004. 1730 [I-D.ietf-eap-keying] 1731 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1732 Management Framework", draft-ietf-eap-keying-08 (work in 1733 progress), October 2005. 1735 [802.11i] IEEE P802, "Wireless MAC and PHY specifications, MAC 1736 security enhancements", IEEE 802.11i, July 2004. 1738 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1739 Networks", RFC 2464, December 1998. 1741 [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 1742 RFC 2720, October 1999. 1744 [RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow 1745 Measurement: Architecture", RFC 2722, October 1999. 1747 Authors' Addresses 1749 Yacine El Mghazli (Editor) 1750 Alcatel 1751 Route de Nozay 1752 Marcoussis 91460 1753 France 1755 Email: yacine.el_mghazli@alcatel.fr 1757 Yoshihiro Ohba 1758 Toshiba America Research, Inc. 1759 1, Telcordia Drive 1760 Piscataway, NJ 08854 1761 USA 1763 Email: yohba@tari.toshiba.com 1765 Julien Bournelle 1766 GET/INT 1767 9, rue Charles Fourier 1768 Evry 91011 1769 France 1771 Email: julien.bournelle@int-evry.fr 1773 Intellectual Property Statement 1775 The IETF takes no position regarding the validity or scope of any 1776 Intellectual Property Rights or other rights that might be claimed to 1777 pertain to the implementation or use of the technology described in 1778 this document or the extent to which any license under such rights 1779 might or might not be available; nor does it represent that it has 1780 made any independent effort to identify any such rights. Information 1781 on the procedures with respect to rights in RFC documents can be 1782 found in BCP 78 and BCP 79. 1784 Copies of IPR disclosures made to the IETF Secretariat and any 1785 assurances of licenses to be made available, or the result of an 1786 attempt made to obtain a general license or permission for the use of 1787 such proprietary rights by implementers or users of this 1788 specification can be obtained from the IETF on-line IPR repository at 1789 http://www.ietf.org/ipr. 1791 The IETF invites any interested party to bring to its attention any 1792 copyrights, patents or patent applications, or other proprietary 1793 rights that may cover technology that may be required to implement 1794 this standard. Please address the information to the IETF at 1795 ietf-ipr@ietf.org. 1797 Disclaimer of Validity 1799 This document and the information contained herein are provided on an 1800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1802 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1803 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1804 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1807 Copyright Statement 1809 Copyright (C) The Internet Society (2006). This document is subject 1810 to the rights, licenses and restrictions contained in BCP 78, and 1811 except as set forth therein, the authors retain all their rights. 1813 Acknowledgment 1815 Funding for the RFC Editor function is currently provided by the 1816 Internet Society.