idnits 2.17.1 draft-ietf-pana-snmp-02.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1515. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 362 instances of lines with control characters in the document. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 22, 2004) is 7126 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-aaa-eap' is defined on line 1402, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 1418, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'I-D.yacine-pana-paa2ep-prot-eval' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'I-D.yacine-pana-paa-ep-reqs' is defined on line 1463, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-06 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-requirements (ref. 'I-D.ietf-pana-requirements') == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-04 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-threats-eval (ref. 'I-D.ietf-pana-threats-eval') == Outdated reference: A later version (-10) exists of draft-ietf-pana-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-framework (ref. 'I-D.ietf-pana-framework') == Outdated reference: A later version (-07) exists of draft-ietf-ipsp-spd-mib-01 == Outdated reference: A later version (-02) exists of draft-ietf-ipsp-ikeaction-mib-01 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-09 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-03 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 3410 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) Summary: 16 errors (**), 0 flaws (~~), 15 warnings (==), 7 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: April 22, 2005 Y. Ohba 5 Toshiba 6 J. Bournelle 7 GET/INT 8 October 22, 2004 10 SNMP usage for PAA-EP interface 11 draft-ietf-pana-snmp-02 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 22, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 The PANA Authentication Agent (PAA) does not necessarily act as an 47 Enforcement Point (EP) to prevent unauthorized access or usage of the 48 network. When a PANA Client successfully authenticates itself to the 49 PAA, EP(s) (e.g., access routers) will need to be suitably notified. 51 The PANA working group mandates the use of Simple Network Management 52 Protocol Version 3 (SNMPv3) to deliver the authorization information 53 to one or more EPs when the PAA is separated from EPs. 55 The present document provides the necessary information and 56 extensions needed to use SNMPv3 as the PAA-EP protocol. 58 Table of Contents 60 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1 PAA/EP separation context . . . . . . . . . . . . . . . . 4 63 2.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. The Internet-Standard Management Framework . . . . . . . . . . 6 65 4. SNMP Applicability with the PANA framework . . . . . . . . . . 7 66 4.1 SNMPv3 General applicability . . . . . . . . . . . . . . . 7 67 4.2 Compliancy of SNMP against the PANA requirements . . . . . 8 68 4.2.1 Authorization Consideration . . . . . . . . . . . . . 8 69 4.2.2 PAA-EP relation . . . . . . . . . . . . . . . . . . . 9 70 4.2.3 Secure Communication . . . . . . . . . . . . . . . . . 9 71 4.2.4 Notification of PaC presence . . . . . . . . . . . . . 9 72 4.2.5 Accounting Consideration . . . . . . . . . . . . . . . 10 73 4.2.6 Peer Liveness Test and Rebooted Peer Detection . . . . 10 74 5. Applicability of IPSec configuration MIBs . . . . . . . . . . 12 75 5.1 General Access Control . . . . . . . . . . . . . . . . . . 12 76 5.2 Network Layer Secure Access Control (IPSec) . . . . . . . 14 77 5.3 Notification of PaC presence . . . . . . . . . . . . . . . 15 78 6. EP Configuration Example . . . . . . . . . . . . . . . . . . . 16 79 6.1 General IP-based Access Control . . . . . . . . . . . . . 16 80 6.2 IPSec-based Access Control . . . . . . . . . . . . . . . . 17 81 7. PANA extension to the IPSec SPD MIB . . . . . . . . . . . . . 20 82 7.1 PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 20 83 7.2 PANA-specific objects definition . . . . . . . . . . . . . 20 84 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 8.1 Security Issue on PaC presence notification . . . . . . . 30 86 8.2 MIB usage example . . . . . . . . . . . . . . . . . . . . 30 87 8.3 Link-layer protection support . . . . . . . . . . . . . . 30 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 91 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 33 92 11.2 Informative References . . . . . . . . . . . . . . . . . . . 35 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35 94 Intellectual Property and Copyright Statements . . . . . . . . 37 96 1. Terminology and Definitions 98 PANA: Protocol for Carrying Authentication for Network Access. 100 PaC (PANA Client): 102 The client side of the protocol that resides in the host device, 103 which is responsible for providing the credentials to prove its 104 identity for network access authorization. A PaC is responsible 105 for requesting network access and engaging in authentication 106 process using the PANA protocol. 108 DI (Device Identifier): 110 The identifier used by the network as a handle to control and 111 police the network access of a client. Depending on the access 112 technology, this identifier might contain any of IP address, 113 link-layer address, switch port number, etc. of a connected 114 device. 116 PAA (PANA Authentication Agent): 118 The access network (server) side entity of the PANA protocol. A 119 PAA is in charge of interfacing with the PaCs for authenticating 120 and authorizing them for the network access service. To this end, 121 the PAA verifies the credentials provided by a PANA client and 122 grants network access service to the device associated with the 123 client and identified by a DI. 124 The PAA is also responsible for updating the access control state 125 (i.e., filters) depending on the creation and deletion of the 126 authorization state. The PAA communicates the updated state to 127 the enforcement points in the network. When the PAA and the EP 128 are separated, a protocol is required to carry the authorized 129 client attributes from the PAA to the EP. SNMP is mandated for 130 this task. 132 EP (Enforcement Point): 134 A node on the access network where per-packet enforcement policies 135 (i.e., filters) are applied on the inbound and outbound traffic of 136 client devices. The EP uses non-cryptographic or cryptographic 137 filters to selectively allow and discard data packets. These 138 filters may be applied at the link-layer or the IP-layer. An EP 139 learns the attributes of the authorized clients (DI and 140 (optionally) cryptographic keys) from the PAA. 142 2. Introduction 144 2.1 PAA/EP separation context 146 PANA enables access control by identifying legitimate clients and 147 generating filtering information for access control mechanisms. 148 [I-D.ietf-pana-framework] defines a general AAA and access control 149 framework. The PANA protocol itself provides client authentication 150 and authorization functionality for securing network access. The 151 other component of a complete solution is the access control which 152 ensures that only authenticated and authorized clients can gain 153 access to the network. 155 Access control can be achieved by placing EPs (Enforcement Points) in 156 the network for policing the traffic flow. EPs should prevent data 157 traffic from and to any unauthorized client unless it's either PANA 158 or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor 159 discovery, DHCP, etc.). 161 Figure 1 below illustrates the functional entities and the interfaces 162 (protocols, APIs) among them. 164 RADIUS/ 165 Diameter/ 166 +-----+ PANA +-----+ LDAP/ API +-----+ 167 | PaC |<----------------->| PAA |<---------------->| AS | 168 +-----+ +-----+ +-----+ 169 ^ ^ 170 | | 171 | +-----+ | 172 IKE/ +-------->| EP |<--------+ SNMP/ API 173 4-way handshake +-----+ 175 Figure 1: PANA Functional Model 177 Some of the entities may be co-located depending on the deployment 178 scenario. 180 The EP on the access network allows general data traffic from any 181 authorized PaC, whereas it allows only limited type of traffic (e.g., 182 PANA, DHCP, router discovery) for the unauthorized PaCs. This 183 ensures that the newly attached clients have the minimum access 184 service to engage in PANA and get authorized for the unlimited 185 service. 187 If the PaC is authorized to gain the access to the network, the PAA 188 also sends the PaC-specific attributes (e.g., IP address, 189 cryptographic keys, etc.) to the EP by using SNMP. The EP uses this 190 information to enforce policy rules allowing data traffic from and to 191 the PaC to pass through. 193 In case a cryptographic access control needs to be enabled after the 194 PANA authentication, a secure association protocol runs between the 195 PaC and the EP. The PaC should already have the input parameters to 196 this process as a result of the successful PANA exchange. Similarly, 197 the EP should have obtained them from the PAA via SNMP. Secure 198 association exchange produces the required security associations 199 between the PaC and the EP to enable per-packet protection. 201 Finally data traffic can start flowing from and to the newly 202 authorized PaC. 204 2.2 Scope 206 Section 3 gives references for the SNMP framework. 208 Section 4 provides a general statement with regards to the 209 applicability of SNMP as the PAA-EP protocol. 211 IPSec MIB modules were found to have general applicability and 212 varying levels of re-usability for PANA EP configuration using SNMP. 213 Section 5 details the applicability of this MIB set to the EP 214 configuration. 216 Section 6 provides usage examples of these MIB modules in the context 217 of PANA. 219 Section 7 defines some additional PANA-specific objects that extend 220 the IPSec SPD-MIB module [I-D.ietf-ipsp-spd-mib] in order to entirely 221 satisfy the PAA-EP interface requirements. 223 Finally, Section 9 addresses the security considerations. 225 3. The Internet-Standard Management Framework 227 For a detailed overview of the documents that describe the current 228 Internet-Standard Management Framework, please refer to section 7 of 229 [RFC3410]. 231 Managed objects are accessed via a virtual information store, termed 232 the Management Information Base or MIB. MIB objects are generally 233 accessed through the Simple Network Management Protocol (SNMP). 234 Objects in the MIB are defined using the mechanisms defined in the 235 Structure of Management Information (SMI). This memo specifies a MIB 236 module that is compliant to the SMIv2, which is described in STD 58 237 [RFC2578], STD 58 [RFC2579] and STD 58 [RFC2580]. 239 4. SNMP Applicability with the PANA framework 241 This section provides a general statement with regards to the 242 applicability of SNMP as the PAA-EP protocol. This analysis of SNMP 243 is specific to SNMPv3, which provides the security required for PANA 244 usage. SNMPv1 and SNMPv2c would be inappropriate for PANA since they 245 have been declared Historic, and because their messages have only 246 trivial security. 248 4.1 SNMPv3 General applicability 250 The primary advantages of SNMPv3 are that it is a mature, well 251 understood protocol, currently deployed in various scenarios, with 252 mature toolsets available for SNMP managers and agents. 254 Application intelligence is captured in MIB modules, rather than in 255 the messaging protocol. MIB modules define a data model of the 256 information that can be collected and configured for a managed 257 functionality. The SNMP messaging protocol transports the data in a 258 standardized format without needing to understand the semantics of 259 the data being transferred. The endpoints of the communication 260 understand the semantics of the data. 262 Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly 263 due to variations in configuration requirements across vendors, few 264 MIB modules have been developed that enable standardized 265 configuration of managed devices across vendors. Since monitoring 266 can be done using only a least-common-denominator subset of 267 information across vendors, many MIB modules have been developed to 268 provide standardized monitoring of managed devices. As a result, 269 SNMP has been used primarily for monitoring rather than for 270 configuring network nodes. 272 SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c 273 versions. Specifically, SNMPv3 shares the separation of data 274 modeling (MIBs) from the protocol to transfer data, so all existing 275 MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, 276 and it shares operations and transport with SNMPv2c. The major 277 difference between SNMPv3 and earlier versions is the addition of 278 strong message security and controlled access to data. 280 SNMPv3 uses the architecture detailed in [RFC3411], where all SNMP 281 entities are capable of performing certain functions, such as the 282 generation of requests, response to requests, the generation of 283 asynchronous notifications, the receipt of notifications, and the 284 proxy-forwarding of SNMP messages. SNMP is used to read and 285 manipulate virtual databases of managed-application-specific 286 operational parameters and statistics, which are defined in MIB 287 modules. 289 4.2 Compliancy of SNMP against the PANA requirements 291 The following sections detail how the PAA-EP protocol requirements 292 are fully supported by SNMP: 294 4.2.1 Authorization Consideration 296 This section discusses PAA-EP communication in terms of authorization 297 aspects. 299 Binary Authorization: 301 Filtering rules to be installed on EP generally include a device 302 identifier of PaC, and also a cryptographic keying material (e.g., 303 IKE [RFC2409] pre-shared key ) when cryptographic data traffic 304 protection is needed. Each keying material is uniquely identified 305 with a keying material name (e.g., ID_KEY_ID in IKE) and has a 306 lifetime for key management, accounting, access control and 307 security reasons in general. 309 PANA management can be modeled in a way that is consistent with 310 existing standard MIB modules, this is detailed in Section 5. 311 Additional PANA-specific objects may be needed and are defined in 312 Section 7. 314 Profile-based authorization: 316 In addition to the device identifier and keying material, the PAA 317 may provide the EP with additional authorization information. For 318 instance, a user may be authorized to access the network within a 319 given class of service or for a maximum amount of units. The type 320 of units can be time (e.g., authorization lifetime), volume (e.g., 321 the number of incoming and/or outgoing packets and/or bytes), 322 service specific or money depending on the type of service event 323 [I-D.ietf-aaa-diameter-cc]. 325 There are two possible models to support this type of 326 authorization: 328 * In the polling model, the PAA (most probably) periodically 329 sends queries to its EP(s) on the current amount of units used 330 by each PaC. 332 * In the notification model, the PAA sends the maximum amount 333 units to EP(s) when a PaC is successfully authenticated and 334 authorized, and waits notification events from EP(s). The 335 notification events are sent by EP(s) when a PaC has spent the 336 maximum amount of units. With the use of SNMPv3 as the PAA-EP 337 protocol, the polling and notification models are supported by 338 SNMP get and notification operations, respectively. 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 5.3 for details on how new and existing SNMP 383 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. There are logically two models with regard to 390 where the accounting client is located. 392 o In the first model, the accounting client is co-located with PAA. 393 The PAA device acts as an accounting client of a AAA protocol. 394 The PAA collects accounting information from the EP(s) it 395 controls, and sends the gathered data to the accounting server by 396 using the AAA protocol. In the case where accounting is performed 397 in usage basis, i.e., the number of transmitted/received 398 octets/packets, the PAA-EP protocol also needs to carry these 399 usage data. 401 o In the second model, the accounting client is co-located with the 402 EP. In this model, the EP device acts as an accounting client of 403 a AAA protocol. The EP obtains the authentication/authorization 404 session identifier for each PaC from the PAA, where the 405 authentication/authorization session identifier is assigned by a 406 AAA protocol running on the PAA, and sends the accounting 407 information directly to the accounting server by using the AAA 408 protocol, without sending the accounting information to the PAA. 410 The authentication/authorization session identifier of a AAA protocol 411 is used by the accounting server to associate accounting information 412 with a particular authentication/authorization session to calculate 413 bills. The authentication/authorization session identifier may or 414 may not be the same as the PANA session identifier. 416 Both models might need for the communicating pair of the PAA and the 417 EP to detect a dead or rebooted peer to avoid possible inaccurate 418 accounting. This aspect is discussed in Section 4.2.6. 420 4.2.6 Peer Liveness Test and Rebooted Peer Detection 422 PAA-EP protocol implementations need to be stateful, when considering 423 the authorization and accounting aspects as described in the previous 424 sections. The stateful nature provides the functionality to detect a 425 dead or rebooted peer in a timely fashion. On the other hand, this 426 does not mean that the PAA-EP protocol itself needs to be stateful. 427 For example, an SNMP entity (i.e., an SNMP engine plus SNMP 428 applications) can generate SNMP queries on a particular MIB at an 429 interval short enough to perform peer liveness test and rebooted peer 430 detection. 432 Also, the peer liveness test and rebooted peer detection need to be 433 performed securely. 435 When SNMPv3 is used as the PAA-EP protocol, the SNMP management 436 framework supports snmpEngineBoots MIB [RFC3411]. By periodically 437 sending SNMP query to the peer to check the current value of this MIB 438 with the use of SNMP Security Subsystem, it is possible for an SNMP 439 entity to securely perform peer liveness test and rebooted peer 440 detection between PAA and EP. 442 When a PAA finds a dead or rebooted EP, the PAA should immediately 443 terminate PANA sessions for PaCs that are authorized for access 444 through the EP. 446 5. Applicability of IPSec configuration MIBs 448 This section details the applicability of existing IPSec 449 configuration MIB modules to the EP configuration. These were found 450 to have general applicability and a fair level of re-usability for 451 the PANA EP configuration: 453 IPSec Security Policy Database (SPD) MIB: 454 [I-D.ietf-ipsp-spd-mib] defines a MIB module for configuration of 455 an IPSec Security Policy Database (SPD). No IPSec or IKE specific 456 actions are defined within this document. 458 IPSec IKE Action MIB: 459 [I-D.ietf-ipsp-ikeaction-mib] defines a MIB module for 460 configuration of an IKE action within the IPSec SPD. 462 The IPSec Configuration MIBs set does not define MIB modules for 463 monitoring the state of an IPSec device. Neither it does define MIB 464 modules for configuring other policy related actions. The purpose of 465 these MIBs is to allow administrators to be able to configure policy 466 with respect to the IPSec [RFC2401]/IKE [RFC2409] protocols. 468 5.1 General Access Control 470 The EP enforces binary authorization by filtering data traffic on the 471 basis of the Device Identifier (DI) of the PaC. The PAA must 472 provision its EPs with DI-based filters in order to control and 473 police the network access of a PaC. According to the definition of 474 the Device Identifier in [I-D.ietf-pana-requirements], such filters - 475 depending on the access technology - might be either a IPv4/6 address 476 or a link-layer address of a connected device. Do note also that a 477 keying material might be provisioned. The particular case where 478 access control is performed using IPSec is specified in 479 [I-D.ietf-pana-ipsec]. The configuration aspects are detailed in 480 Section 5.2. 482 The IPSec SPD MIB module (SPD-MIB) is designed to configure an IPSec 483 security policy database in a policy and rule oriented fashion. This 484 module is divided into 3 portions (Rules, Filters, Actions). 485 Specifically, SPD-MIB provides a generic mechanism for performing 486 packet processing based on a rule set. 488 The policy-based packet filtering and the corresponding execution of 489 actions is of a more general nature than for IPSec configuration 490 only, such as for configuration of a firewall. Rules within the 491 IPSec SPD-MIB are generic and simply bind a filter to an action. 492 Filters provided within the SPD-MIB itself are numerous and fairly 493 complete for most common packet filtering usage but externally 494 defined filters are supported. 496 Below are basic DI-based filters and static actions that are used -- 497 together with the other SPD tables -- to enforce binary packet 498 authorization at the EP: 500 -- Ipv4/v6 address-based filter: 502 For Ipv4/v6 address-based filters provisioning, the IPSec SPD-MIB 503 provides means to filter the traffic based on the IP header 504 information. SPD-MIB "spdIpHeaderFilter" table provides such 505 facilities: one can define the various tests that are used when 506 evaluating a given IP packet. The various tests definable in this 507 table are as follows: 509 * Source Address Match 510 * Destination Address Match 511 * Source Port Range Match 512 * Destination Port Range Match 513 * Protocol Match 514 * IPv6 Flow Label Match (Ipv6 only) 516 The results of each test are ANDed together to produce the result 517 of the entire filter. 519 -- L2 address-based filter: 521 [I-D.ietf-pana-pana] says the Device-Id AVP (code 1025) is of 522 Address Type [RFC3588]. The content for link-layer addresses is 523 expected to be specified in specific documents that describe how 524 IP operates over different link-layers. For instance, [RFC2464]. 525 To this end, additional filters are designed in the present 526 document. Section 7 defines a link-layer filter table, which test 527 the L2 address (e.g. MAC address, port, DSL line) of a given 528 packet. 529 Do note that the definition of this table does not assume the 530 usage of any particular Link layer. 532 -- Static Actions: 534 The actions encapsulated within the SPD-MIB module are basic 535 drop/accept actions. These are sufficient to perform EP general 536 binary authorization enforcement at the EP. 537 When profile-based authorization information is provided to the 538 EP, more advanced actions like classifiers, meters and schedulers 539 might be configured by the PAA. This is out of the scope of the 540 present document. 542 5.2 Network Layer Secure Access Control (IPSec) 544 The PANA protocol authenticates the client and also establishes a 545 PANA security association between the PANA client and PANA 546 authentication agent at the end of successful authentication. The 547 PAA indicates the results of the authentication using the 548 PANA-Bind-Request (PBR) message wherein it can indicate the access 549 control method enforced by the access network and the IP address of 550 the corresponding EP. 552 When IPSec is used to perform access control, the PANA protocol 553 [I-D.ietf-pana-pana] does not discuss any details of IPSec [RFC2401] 554 SA establishment. Indeed, [I-D.ietf-pana-ipsec] discusses the 555 details for establishing an IPSec security association between the 556 PaC and the EP. When the IPSec SA is successfully established, it 557 can be used to enforce access control and specifically used to 558 prevent the service theft mentioned in [I-D.ietf-pana-threats-eval]. 560 In this particular context, one assumes that the following have 561 already happened before the IPSec SA is established: 563 1. PANA client (PaC) and PAA mutually authenticate each other using 564 EAP methods that derive the AAA-Key [I-D.ietf-eap-keying]. 565 2. PaC learns the IP address of the Enforcement point (EP) during 566 the PANA exchange. 567 3. PaC learns that the network uses IPSec [RFC2401] for securing the 568 link between PaC and EP during the PANA exchange (PBR message). 569 4. PaC configures an IP address address before the PANA protocol 570 begins (the pre-PANA Address (PRPA), see [I-D.ietf-pana-pana]). 572 The IPSec IKE Action MIB module (IKEACTION-MIB) works within the 573 framework of the IPSec SPD-MIB. It can be referenced as an action by 574 the SPD-MIB and is used to configure IKE negotiations between network 575 devices. Hence, together with the SPD-MIB, the IKEACTION-MIB module 576 enables the PAA to configure IPSEC-based access control at the EP. 578 The PAA is then responsible to communicate to EP the following 579 information before IKE phase 1 exchange begins between PaC and EP: 581 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: 590 An IP Header Filter of the SPD-MIB is used for configuring the SPD 591 in a similar manner than what is described in Section 5.1. 593 The Key-Id and PANA session ID: 594 [I-D.ietf-pana-ipsec] states that Pac and EP should use the PANA 595 session ID concatenated with the AAA-key as the value of the 596 ID_KEY_ID in aggressive mode for establishing the phase 1 SA. 597 Section 6 details usage examples that illustrate the way the 598 IKEACTION-MIB is used for this purpose. 600 5.3 Notification of PaC presence 602 The SPD-MIB provides a means to notify to the SNMP manager (PAA) 603 information on packets matching/not matching the filters of given 604 rule. Such notification mechanisms and objects can be re-used for 605 notifying the PAA that unauthorized packets are trying to pass 606 through the EP. 608 Section 7 defines new notifications, which aims at satisfying this 609 requirement. It re-uses existing notification variable objects 610 pre-defined in the SPD-MIB. 612 These "New PaC" notifications (panaNewPacIPNotification and 613 panaNewPaCL2Notification) are triggered when the the EP detects 614 traffic coming from an unauthorized source. 616 If the traffic detected is an IP flow, the objects sent must include 617 spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, and 618 spdIPDestinationAddress objects to indicate the packet source and 619 destination of the packet that triggered the action. Additionally, 620 the spdIPInterfaceType and spdIPInterfaceAddress objects are included 621 to indicate which interface the action was executed in association 622 with and if the packet was inbound or outbound through the endpoint. 623 See [I-D.ietf-ipsp-spd-mib] for further details. 625 If the traffic detected is Link-layer traffic, the objects sent must 626 include the index of the interface which detected such traffic and 627 potentially the L2 address source of the traffic. See Section 7 for 628 further details. 630 6. EP Configuration Example 632 Below are usage examples of the IPSec modules in the PANA context. 634 6.1 General IP-based Access Control 636 Below is a usage example of the IPSec modules. In this example, we 637 need to configure the SPD so that EP accepts IP packets coming 638 from/going to the PaC. 640 The "EndPoint to Group" table is used to map policy (groupings) onto 641 an endpoint (EP-ADDR is the IP address) where traffic is to pass by. 642 Any policy group assigned to an endpoint is then used to control 643 access to the traffic passing by it. 645 So far, we define below two policy groups at the EP interface 646 ("EP-SPD-IN" and "EP-SPD-OUT"). 648 spdEndpointToGroupTable.1 = 649 spdEndGroupDirection = incoming; 650 spdEndGroupIdentType = IPv4; 651 spdEndGroupAddress = EP-ADDR; 652 spdEndGroupName = "EP-SPD-IN"; 654 spdEndpointToGroupTable.2 = 655 spdEndGroupDirection = outgoing; 656 spdEndGroupIdentType = IPv4; 657 spdEndGroupAddress = EP-ADDR; 658 spdEndGroupName = "EP-SPD-OUT"; 660 Within each of the policy group defined above, we define a rule 661 dedicated to the treatment of packets coming from/going to "PaC1" and 662 the EP we are provisioning. 664 spdGroupContentsTable.2 = 665 spdGroupContName = "EP-SPD-IN"; 666 spdGroupContPriority = 1; 667 spdGroupContFilter = spdIpHeaderFilterTable.1; 668 spdGroupContComponentType = rule; 669 spdGroupContComponentName = "EP-PaC1-IN"; 671 spdGroupContentsTable.2 = 672 spdGroupContName = "EP-SPD-OUT"; 673 spdGroupContPriority = 1; 674 spdGroupContFilter = spdIpHeaderFilterTable.2; 675 spdGroupContComponentType = rule; 676 spdGroupContComponentName = "EP-PaC1-OUT"; 678 We define two filters in the "IP Header filter" table: one match IP 679 packets coming from the PaC, the other match IP packets going to the 680 PaC. 682 spdIpHeaderFilterTable.1 = 683 spdIpHeadFiltName = "PaC1-IP@ Filter SOURCE"; 684 spdIpHeadFiltType = { sourceAddress ON }; 685 spdIpHeadFiltIPVersion = v4; 686 spdIpHeadFiltSrcAddressBegin = PaC1-IP@; 687 spdIpHeadFiltSrcAddressEnd = PaC1-IP@; 689 spdIpHeaderFilterTable.2 = 690 spdIpHeadFiltName = "PaC1-IP@ Filter DEST"; 691 spdIpHeadFiltType = { destAddress ON }; 692 spdIpHeadFiltIPVersion = v4; 693 spdIpHeadFiltSrcAddressBegin = PaC1-IP@; 694 spdIpHeadFiltSrcAddressEnd = PaC1-IP@; 696 The "Rule Defininition" table links a rule with a given action in the 697 SPD action MIB. E.g. the following entries links the two filters 698 defined above with the "accept" action statically defined in the SPD 699 MIB (spdStaticActions.3). 701 spdRuleDefinitionTable.1 = 702 spdRuleDefName = "PaC1-ACCEPT-IN"; 703 spdRuleDefDescription = "Allow Incoming IP packets from PaC1"; 704 spdRuleDefFilter = spdIpHeaderFilterTable.1; 705 spdRuleDefFilterNegated = false (default); 706 spdRuleDefAction = spdStaticActions.3; 708 spdRuleDefinitionTable.2 = 709 spdRuleDefName = "PaC1-ACCEPT-OUT"; 710 spdRuleDefDescription = "Allow Outgoing IP packets to PaC1"; 711 spdRuleDefFilter = spdIpHeaderFilterTable.2; 712 spdRuleDefFilterNegated = false (default); 713 spdRuleDefAction = spdStaticActions.3; 715 This means that any packet coming from/going to the PaC is now 716 allowed to go through the EP (via EP-ADDR endpoint). 718 6.2 IPSec-based Access Control 720 In this section we consider the case when IPSec is used to control 721 access at the IP level. In order to avoid many redundancies, the 722 previous configuration set is still valid. See below a usage example 723 of IKEACTION-MIB. 725 -- IKE Phase 1 configuration (agressive mode): 727 We define a rule in policy group "EP-SPD-IN" of the SPD MIB, using 728 the "Group contents" table. This rule is dedicated to all IKE phase 729 1 traffic coming to the EP on this interface: 731 spdGroupContentsTable.1 = 732 spdGroupContName = "EP-SPD-IN"; 733 spdGroupContPriority = 1; 734 spdGroupContFilter = ipiaStaticFilters.1; 735 spdGroupContComponentType = sub-group; 736 spdGroupContComponentName = "EP-IKE-Phase1-IN"; 738 And within this IKE-specific policy sub-group we now specify the rule 739 to apply for the IKE traffic coming from PaC1. 741 spdGroupContentsTable.2 = 742 spdGroupContName = "EP-IKE-Phase1-IN"; 743 spdGroupContPriority = 1; 744 spdGroupContFilter = spdIpHeaderFilterTable.1; 745 spdGroupContComponentType = rule; 746 spdGroupContComponentName = "PaC1-IKE-RULE"; 748 The spdIpHeaderFilterTable.1 entry has been defined in the previous 749 seciton. 751 The "Rule Defininition" table links a rule with a given action in the 752 IKE action MIB. This action will be triggereed upon reception at the 753 EP of an IKE packet coming from PaC1. 755 spdRuleDefinitionTable.3 = 756 spdRuleDefName = "PaC1-IKE-RULE"; 757 spdRuleDefDescription = "IPSec Access Control for PaC1"; 758 spdRuleDefFilter = spdIpHeaderFilterTable.1; 759 spdRuleDefFilterNegated = false (default); 760 spdRuleDefAction = spdIkeActionTable.1; 762 The "IKE action" entry below specifies the main parameters for the 763 IKE exchanges. 765 ipiaIkeActionTable.1 = 766 ipiaIkeActName = "PaC1-IKE"; 767 ipiaIkeActParametersName = "SA-PaC1"; 768 ipiaIkeActThresholdDerivedKeys = 100 (default); 769 ipiaIkeActExchangeMode = aggressive; 770 ipiaIkeActAgressiveModeGroupId = xxx [Diffie-Hellman values]; 771 ipiaIkeActIdentityType = id_Key_Id; 772 ipiaIkeActIdentityContext = "PANA"; 773 ipiaIkeActPeerName = "PaC1"; 775 ipiaSaNegotiationParametersTable.1 = 776 ipiaSaNegParamName = "SA-PaC1"; 777 ipiaSaNegParamMinLifetimeSecs = xxx; 778 ipiaSaNegParamMinLifetimeKB = xxx; 779 ipiaSaNegParamRefreshThreshSecs = xxx; 780 ipiaSaNegParamRefreshThresholdKB = xxx; 781 ipiaSaNegParamIdleDurationSecs = xxx; 783 The "Peer Identity" table specifically informs the EP on the value of 784 the idKeyId to use in IKE messages with PaC1: 786 ipiaPeerIdentityFilterTable.1 = 787 ipiaPeerIdFiltName = "PaC1"; 788 ipiaPeerIdFiltIdentityType = id_key_id; 789 ipiaPeerIdFiltIdentityValue = "PANA-Session-Id|PANA-Key-Id"; 791 The following entry links a given identity (PaC1) with an entry in 792 the "Credentials" table. 794 ipiaIkeIdentityTable.1 = 795 spdEndGroupIdentType = IPv4; 796 spdEndGroupAddress = EP-ADDR; 797 ipiaIkeActIdentityType = id_key_id; 798 ipiaIkeActIdentityContext = PANA; 799 ipiaIkeIdCredentialName = "PaC1-PSK"; 801 Finally the pre-shared key derivated at the PAA is set here: 803 ipiaCredentialFilterTable.1 = 804 ipiaCredFiltName = "PaC1-PSK"; 805 ipiaCredFiltCredentialType = sharedSecret; 806 ipiaCredFiltMatchFieldName = none; 807 ipiaCredFiltMatchFieldValue = "PSK-from-PAA"; 809 7. PANA extension to the IPSec SPD MIB 811 Many existing IPSec MIB objects defined in the IPSec Configuration 812 MIB modules can be efficiently re-used for the PANA-specific needs. 813 This is detailed in Section 5. 815 The following sections define additional PANA-specific objects that 816 extend the IPSec MIB module in order to entirely satisfy the PAA-EP 817 interface requirements. 819 7.1 PANA MIB Overview 821 o Link-Layer filter table 822 o New PaC notification 824 7.2 PANA-specific objects definition 826 PANA-EP-MIB DEFINITIONS ::= BEGIN 828 IMPORTS 830 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32 831 FROM SNMPv2-SMI 833 RowStatus, PhysAddress, StorageType, TimeStamp 834 FROM SNMPv2-TC 836 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 837 FROM SNMPv2-CONF 839 SnmpAdminString 840 FROM SNMP-FRAMEWORK-MIB 842 InterfaceIndex 843 FROM IF-MIB 845 spdMIB, spdActionExecuted, spdIPInterfaceType, spdIPInterfaceAddress, 846 spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, 847 spdIPDestinationAddress, spdPacketDirection 848 FROM IPSEC-SPD-MIB; 850 -- Module identity 851 -- 853 panaMIB MODULE-IDENTITY 854 LAST-UPDATED 855 "200410220000Z" -- 22 October 2004 856 ORGANIZATION 857 "IETF PANA Working Group" 858 CONTACT-INFO 859 "Yacine El Mghazli 860 Alcatel 861 91460 Marcoussis, France 862 Phone: +33 1 69 63 41 87 863 Email: yacine.el_mghazli@alcatel.fr" 864 DESCRIPTION 865 "The MIB module for defining additional PANA-specific objects to 866 the IPSec SPD MIB. Copyright (C) The Internet Society (2003). 867 This version of this MIB module is part of RFC XXXX, see the 868 RFC itself for full legal notices." 870 -- Revision History 871 REVISION 872 "200410220000Z" -- 22 October 2004 873 DESCRIPTION 874 "Version 02, draft-ietf-pana-snmp-02.txt" 875 REVISION 876 "200402050000Z" -- 05 February 2004 877 DESCRIPTION 878 "Version 01, draft-yacine-pana-paa2ep-snmp-01.txt" 879 REVISION 880 "200310310000Z" -- 31 October 2003 881 DESCRIPTION 882 "Initial version, draft-yacine-pana-paa2ep-snmp-00.txt" 883 ::= { spdMIB 99999999 } -- XXX to be assigned by IANA 885 -- 886 -- groups of related objects 887 -- 889 panaConfigObjects OBJECT IDENTIFIER 890 ::= { panaMIB 1 } 891 panaNotificationObjects OBJECT IDENTIFIER 892 ::= { panaMIB 2} 893 panaConformanceObjects OBJECT IDENTIFIER 894 ::= { panaMIB 3 } 896 -- 897 -- Textual Conventions 898 -- 900 -- TBD. 902 -- 903 -- PANA Additional Filters Objects 904 -- 906 -- 907 -- The Link-layer Filter Table 908 -- 910 panaL2FilterTable OBJECT-TYPE 911 SYNTAX SEQUENCE OF PanaL2FilterEntry 912 MAX-ACCESS not-accessible 913 STATUS current 914 DESCRIPTION 915 "Link-layer filter definitions." 916 ::= { panaConfigObjects 1 } 918 panaL2FilterEntry OBJECT-TYPE 919 SYNTAX PanaL2FilterEntry 920 MAX-ACCESS not-accessible 921 STATUS current 922 DESCRIPTION 923 "An entry in the Link-layer filter table." 924 INDEX { panaL2FiltEpIfIndex } 925 ::= { panaL2FilterTable 1 } 927 PanaL2FilterEntry ::= SEQUENCE { 928 panaL2FiltEpIfIndex InterfaceIndex, 929 panaL2FiltAddr PhysAddress, 930 panaL2FiltLastChanged TimeStamp, 931 panaL2FiltStorageType StorageType, 932 panaL2FiltRowStatus RowStatus 933 } 935 panaL2FiltEpIfIndex OBJECT-TYPE 936 SYNTAX InterfaceIndex 937 MAX-ACCESS read-create 938 STATUS current 939 DESCRIPTION 940 "The index identifying the EP interface where the filter 941 policy must be enforced on." 942 ::= { panaL2FilterEntry 1 } 944 panaL2FiltAddr OBJECT-TYPE 945 SYNTAX PhysAddress 946 MAX-ACCESS read-create 947 STATUS current 948 DESCRIPTION 949 "The authorized device Link-layer address (DI). For 950 example, for a 802.x interface, this object normally 951 contains a MAC address. For interfaces which do not have such 952 an address (e.g., a serial line), this object should contain 953 an octet string of zero length." 954 ::= { panaL2FilterEntry 2 } 956 panaL2FiltLastChanged OBJECT-TYPE 957 SYNTAX TimeStamp 958 MAX-ACCESS read-only 959 STATUS current 960 DESCRIPTION 961 "The value of sysUpTime when this row was last modified or 962 created either through SNMP SETs or by some other external 963 means." 964 ::= { panaL2FilterEntry 3 } 966 panaL2FiltStorageType OBJECT-TYPE 967 SYNTAX StorageType 968 MAX-ACCESS read-create 969 STATUS current 970 DESCRIPTION 971 "The storage type for this row. Rows in this table which were 972 created through an external process may have a storage type 973 of readOnly or permanent." 974 DEFVAL { nonVolatile } 975 ::= { panaL2FilterEntry 4 } 977 panaL2FiltRowStatus OBJECT-TYPE 978 SYNTAX RowStatus 979 MAX-ACCESS read-create 980 STATUS current 981 DESCRIPTION 982 "This object indicates the conceptual status of this row." 983 ::= { panaL2FilterEntry 5 } 985 -- 986 -- 987 -- Notification objects information 988 -- 989 -- 991 panaNotificationVariables OBJECT IDENTIFIER ::= 992 { panaNotificationObjects 1 } 994 panaNotifications OBJECT IDENTIFIER ::= 995 { panaNotificationObjects 0 } 996 panaEpIfIndex OBJECT-TYPE 997 SYNTAX InterfaceIndex 998 MAX-ACCESS accessible-for-notify 999 STATUS current 1000 DESCRIPTION 1001 "Contains the interface index on which the packet triggered 1002 the notification in question." 1003 ::= { panaNotificationVariables 1 } 1005 panaL2SourceAddress OBJECT-TYPE 1006 SYNTAX PhysAddress 1007 MAX-ACCESS accessible-for-notify 1008 STATUS current 1009 DESCRIPTION 1010 "Contains the source Link layer address of the packet which 1011 triggered the notification in question. For 1012 example, for a 802.x frame, this object normally 1013 contains a MAC address. For interfaces which do not have such 1014 an address (e.g., a serial line), this object should contain 1015 an octet string of zero length. " 1016 ::= { panaNotificationVariables 2 } 1018 panaNewPacIPNotification NOTIFICATION-TYPE 1019 OBJECTS { 1020 spdActionExecuted, 1021 spdIPInterfaceType, 1022 spdIPInterfaceAddress, 1023 spdIPSourceType, 1024 spdIPSourceAddress, 1025 spdIPDestinationType, 1026 spdIPDestinationAddress} 1027 STATUS current 1028 DESCRIPTION 1029 "Notification that EP detected IP traffic coming from an 1030 unauthorized source." 1031 ::= { panaNotifications 1 } 1033 panaNewPacL2Notification NOTIFICATION-TYPE 1034 OBJECTS { 1035 spdActionExecuted, 1036 panaEpIfIndex, 1037 panaL2SourceAddress 1038 } 1039 STATUS current 1040 DESCRIPTION 1041 "Notification that EP detected L2 traffic coming from an 1042 unauthorized source. " 1043 ::= { panaNotifications 2 } 1045 -- 1046 -- 1047 -- Conformance information 1048 -- 1049 -- 1051 panaGroups OBJECT IDENTIFIER 1052 ::= { panaConformanceObjects 1 } 1053 panaCompliances OBJECT IDENTIFIER 1054 ::= { panaConformanceObjects 2 } 1056 -- 1057 -- Compliance Groups Definitions 1058 -- 1060 panaL2FilterGroup OBJECT-GROUP 1061 OBJECTS { 1062 panaL2FiltAddr, 1063 panaL2FiltLastChanged, 1064 panaL2FiltStorageType, 1065 panaL2FiltRowStatus } 1066 STATUS current 1067 DESCRIPTION 1068 "The Link-layer Filter Group." 1069 ::= { panaGroups 1 } 1071 panaNewPacL2NotificationObjectsGroup OBJECT-GROUP 1072 OBJECTS { 1073 panaEpIfIndex, 1074 panaL2SourceAddress} 1075 STATUS current 1076 DESCRIPTION 1077 "PaC Presence Notification Objects Group." 1078 ::= { panaGroups 2 } 1080 panaNewPacNotificationGroup NOTIFICATION-GROUP 1081 NOTIFICATIONS { 1082 panaNewPacIPNotification, 1083 panaNewPacL2Notification} 1084 STATUS current 1085 DESCRIPTION 1086 "PaC Presence Notification Group." 1087 ::= { panaGroups 3 } 1088 -- 1089 -- Compliance statements 1090 -- 1092 panaFilterCompliance MODULE-COMPLIANCE 1093 STATUS current 1094 DESCRIPTION 1095 "The compliance statement for SNMP entities that support 1096 PANA DI-based filtering." 1098 MODULE -- This Module 1100 MANDATORY-GROUPS { panaL2FilterGroup } 1102 OBJECT panaL2FiltRowStatus 1103 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1104 DESCRIPTION 1105 "Support of the values notInService(2), notReady(3), 1106 and createAndWait(5) is not required." 1108 OBJECT panaL2FiltLastChanged 1109 MIN-ACCESS not-accessible 1110 DESCRIPTION 1111 "This object not required for compliance." 1113 MODULE IPSEC-SPD-MIB 1115 MANDATORY-GROUPS { 1116 spdEndpointGroup, 1117 spdGroupContentsGroup, 1118 spdRuleDefinitionGroup, 1119 spdIPHeaderFilterGroup, 1120 spdStaticFilterGroup, 1121 spdStaticActionGroup } 1123 GROUP spdIpsecSystemPolicyNameGroup 1124 DESCRIPTION 1125 "This group is mandatory for IPsec Policy 1126 implementations which support a system policy group 1127 name." 1129 GROUP spdCompoundFilterGroup 1130 DESCRIPTION 1131 "This group is mandatory for IPsec Policy 1132 implementations which support compound filters." 1134 GROUP spdCompoundActionGroup 1135 DESCRIPTION 1136 "This group is mandatory for IPsec Policy 1137 implementations which support compound actions." 1139 OBJECT spdEndGroupRowStatus 1140 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1141 DESCRIPTION 1142 "Support of the values notInService(2), notReady(3), 1143 and createAndWait(5) is not required." 1145 OBJECT spdEndGroupLastChanged 1146 MIN-ACCESS not-accessible 1147 DESCRIPTION 1148 "This object not required for compliance." 1150 OBJECT spdGroupContComponentType 1151 SYNTAX INTEGER { rule(2) } 1152 DESCRIPTION 1153 "Support of the value group(1) is only required for 1154 implementations which support Policy Groups within 1155 Policy Groups." 1157 OBJECT spdGroupContRowStatus 1158 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1159 DESCRIPTION 1160 "Support of the values notInService(2), notReady(3), 1161 and createAndWait(5) is not required." 1163 OBJECT spdGroupContLastChanged 1164 MIN-ACCESS not-accessible 1165 DESCRIPTION 1166 "This object not required for compliance." 1168 OBJECT spdRuleDefRowStatus 1169 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1170 DESCRIPTION 1171 "Support of the values notInService(2), notReady(3), 1172 and createAndWait(5) is not required." 1174 OBJECT spdRuleDefLastChanged 1175 MIN-ACCESS not-accessible 1176 DESCRIPTION 1177 "This object not required for compliance." 1179 OBJECT spdCompFiltRowStatus 1180 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1181 DESCRIPTION 1182 "Support of the values notInService(2), notReady(3), 1183 and createAndWait(5) is not required." 1185 OBJECT spdCompFiltLastChanged 1186 MIN-ACCESS not-accessible 1187 DESCRIPTION 1188 "This object not required for compliance." 1190 OBJECT spdSubFiltRowStatus 1191 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1192 DESCRIPTION 1193 "Support of the values notInService(2), notReady(3), 1194 and createAndWait(5) is not required." 1196 OBJECT spdSubFiltLastChanged 1197 MIN-ACCESS not-accessible 1198 DESCRIPTION 1199 "This object not required for compliance." 1201 OBJECT spdIpHeadFiltIPVersion 1202 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 1203 DESCRIPTION 1204 "Only the ipv4 and ipv6 values make sense for this 1205 object." 1207 OBJECT spdIpHeadFiltRowStatus 1208 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1209 DESCRIPTION 1210 "Support of the values notInService(2), notReady(3), 1211 and createAndWait(5) is not required." 1213 OBJECT spdIpHeadFiltLastChanged 1214 MIN-ACCESS not-accessible 1215 DESCRIPTION 1216 "This object not required for compliance." 1218 OBJECT spdCompActRowStatus 1219 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1220 DESCRIPTION 1221 "Support of the values notInService(2), notReady(3), 1222 and createAndWait(5) is not required." 1224 OBJECT spdCompActLastChanged 1225 MIN-ACCESS not-accessible 1226 DESCRIPTION 1227 "This object not required for compliance." 1229 OBJECT spdSubActRowStatus 1230 SYNTAX RowStatus { active(1), createAndGo(4), destroy(6) } 1231 DESCRIPTION 1232 "Support of the values notInService(2), notReady(3), 1233 and createAndWait(5) is not required." 1235 OBJECT spdSubActLastChanged 1236 MIN-ACCESS not-accessible 1237 DESCRIPTION 1238 "This object not required for compliance." 1240 ::= { panaCompliances 1 } 1242 panaNewPacNotificationCompliance MODULE-COMPLIANCE 1243 STATUS current 1244 DESCRIPTION 1245 "The compliance statement for SNMP entities that support 1246 new PaC presence Notification." 1248 MODULE -- This Module 1250 MANDATORY-GROUPS { 1251 panaNewPacL2NotificationObjectsGroup, 1252 panaNewPacNotificationGroup 1253 } 1255 MODULE IPSEC-SPD-MIB 1257 MANDATORY-GROUPS { spdActionLoggingObjectGroup } 1259 ::= { panaCompliances 2 } 1261 END 1263 8. Open Issues 1265 8.1 Security Issue on PaC presence notification 1267 It has been reported that the PANA-specific notification of PaC 1268 presence could be used to overwhelm an SNMP application, thus 1269 creating a DoS attack on the management of the network. A attacker 1270 could detect that such notifications are sent by multiple devices, 1271 and the attacker could deliberately send lots of traffic through the 1272 devices. 1274 8.2 MIB usage example 1276 The MIB usage example (Section 6) needs to be further developped with 1277 the support of the IPSP working group. 1279 8.3 Link-layer protection support 1281 [I-D.ietf-pana-framework] envisages the case, where enabling 1282 link-layer ciphering (e.g. [802.11i]) or network-layer ciphering 1283 might rely on PANA authentication. The user and network then have to 1284 make sure an appropriate EAP method that can generate required keying 1285 materials is used. Once the keying material is available, it needs 1286 to be provided to the EP(s) for use with ciphering. 1288 Network-layer ciphering configuration, i.e., IPsec, including IKE 1289 configuration is fully supported in the present document. 1291 However link-layer ciphers control is not supported yet. The PANA 1292 working group must define the L2 techniques supported (e.g.[802.11i]) 1293 for realizing this feature and the present document should take it 1294 into account. 1296 9. Security Considerations 1298 The MIB defined in the present document relates to a system which 1299 will provide network access. As such, improper manipulation of the 1300 objects represented by this MIB may result in denial of service to a 1301 large number of end-users. In addition, manipulation of the 1302 panaL2FilterTable and spdIpHeaderFilterTable may allow an end-user to 1303 gain network access, spoof their IP addresses, change the authorized 1304 device identifiers, or affect other end-users in either a positive or 1305 negative manner. 1307 There are a number of management objects defined in this MIB module 1308 with a MAX-ACCESS clause of read-write and/or read-create. Such 1309 objects may be considered sensitive or vulnerable in some network 1310 environments. The support for SET operations in a non-secure 1311 environment without proper protection can have a negative effect on 1312 network operations. These are the tables and objects and their 1313 sensitivity/vulnerability: 1315 o The use of panaIPL2FilterTable to specify which Link-layer 1316 addresses are authorized to access the network is considered to be 1317 only limited protection and does not protect against attacks which 1318 spoof the management station's IP address. The use of SNMPv3 1319 security is mandated. Specifically, SNMPv3 VACM and USM MUST be 1320 used with any v3 agent which implements this MIB. 1322 SNMP versions prior to SNMPv3 did not include adequate security. 1323 Even if the network itself is secure (for example by using IPSec), 1324 even then, there is no control as to who on the secure network is 1325 allowed to access and GET/SET (read/change/create/delete) the objects 1326 in this MIB module. 1328 It is RECOMMENDED that implementers consider the security features as 1329 provided by the SNMPv3 framework (see [RFC3410], section 8), 1330 including full support for the SNMPv3 cryptographic mechanisms (for 1331 authentication and privacy). 1333 Further, deployment of SNMP versions prior to SNMPv3 is NOT 1334 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 1335 enable cryptographic security. It is then a customer/operator 1336 responsibility to ensure that the SNMP entity giving access to an 1337 instance of this MIB module is properly configured to give access to 1338 the objects only to those principals (users) that have legitimate 1339 rights to indeed GET or SET (change/create/delete) them. 1341 10. Acknowledgements 1343 This document originaly leverages on similar works done in the MIDCOM 1344 working group. Thanks to the authors of those IDs. 1346 The author would like to thank Thomas Moore and Olivier Marce for 1347 their grateful help during the edition of this document. 1349 11. References 1351 11.1 Normative References 1353 [I-D.ietf-pana-pana] 1354 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 1355 Yegin, "Protocol for Carrying Authentication for Network 1356 Access (PANA)", draft-ietf-pana-pana-06 (work in 1357 progress), October 2004. 1359 [I-D.ietf-pana-requirements] 1360 Yegin, A. and Y. Ohba, "Protocol for Carrying 1361 Authentication for Network Access (PANA)Requirements", 1362 draft-ietf-pana-requirements-09 (work in progress), August 1363 2004. 1365 [I-D.ietf-pana-ipsec] 1366 Parthasarathy, M., "PANA enabling IPsec based Access 1367 Control", draft-ietf-pana-ipsec-04 (work in progress), 1368 September 2004. 1370 [I-D.ietf-pana-threats-eval] 1371 Parthasarathy, M., "Protocol for Carrying Authentication 1372 and Network Access Threat Analysis and Security 1373 Requirements", draft-ietf-pana-threats-eval-07 (work in 1374 progress), August 2004. 1376 [I-D.ietf-pana-framework] 1377 Jayaraman, P., "PANA Framework", 1378 draft-ietf-pana-framework-02 (work in progress), September 1379 2004. 1381 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 1382 (USM) for version 3 of the Simple Network Management 1383 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 1385 [I-D.ietf-ipsp-spd-mib] 1386 Hardaker, W., "IPsec Security Policy Database 1387 Configuration MIB", draft-ietf-ipsp-spd-mib-01 (work in 1388 progress), October 2004. 1390 [I-D.ietf-ipsp-ikeaction-mib] 1391 Hardaker, W., "IPsec Security Policy IKE Action MIB", 1392 draft-ietf-ipsp-ikeaction-mib-01 (work in progress), 1393 October 2004. 1395 [I-D.ietf-aaa-diameter-cc] 1396 Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H. 1398 Hakala, "Diameter Credit-control Application", 1399 draft-ietf-aaa-diameter-cc-06 (work in progress), August 1400 2004. 1402 [I-D.ietf-aaa-eap] 1403 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1404 Authentication Protocol (EAP) Application", 1405 draft-ietf-aaa-eap-09 (work in progress), August 2004. 1407 [I-D.ietf-eap-keying] 1408 Aboba, B., "Extensible Authentication Protocol (EAP) Key 1409 Management Framework", draft-ietf-eap-keying-03 (work in 1410 progress), July 2004. 1412 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1413 Internet Protocol", RFC 2401, November 1998. 1415 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1416 (IKE)", RFC 2409, November 1998. 1418 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1419 3", BCP 9, RFC 2026, October 1996. 1421 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1422 "Introduction and Applicability Statements for 1423 Internet-Standard Management Framework", RFC 3410, 1424 December 2002. 1426 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An 1427 Architecture for Describing Simple Network Management 1428 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1429 December 2002. 1431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1432 Requirement Levels", BCP 14, RFC 2119, March 1997. 1434 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1435 McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of 1436 Management Information Version 2 (SMIv2)", STD 58, RFC 1437 2578, April 1999. 1439 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1440 McCloghrie, K., Rose, M. and S. Waldbusser, "Textual 1441 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 1443 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 1444 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1445 April 1999. 1447 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1448 Networks", RFC 2464, December 1998. 1450 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1451 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1453 [802.11i] IEEE P802, "Wireless MAC and PHY specifications, MAC 1454 security enhancements", IEEE 802.11i, July 2004. 1456 11.2 Informative References 1458 [I-D.yacine-pana-paa2ep-prot-eval] 1459 Mghazli, Y., "PANA PAA-EP protocol considerations", 1460 draft-yacine-pana-paa2ep-prot-eval-00 (work in progress), 1461 October 2003. 1463 [I-D.yacine-pana-paa-ep-reqs] 1464 Mghazli, Y., "PANA PAA-EP Protocol Requirements", 1465 draft-yacine-pana-paa-ep-reqs-00 (work in progress), 1466 October 2003. 1468 Authors' Addresses 1470 Yacine El Mghazli (Editor) 1471 Alcatel 1472 Route de Nozay 1473 Marcoussis 91460 1474 France 1476 EMail: yacine.el_mghazli@alcatel.fr 1478 Yoshihiro Ohba 1479 Toshiba America Research, Inc. 1480 1, Telcordia Drive 1481 Piscataway, NJ 08854 1482 USA 1484 EMail: yohba@tari.toshiba.com 1485 Julien Bournelle 1486 GET/INT 1487 9, rue Charles Fourier 1488 Evry 91011 1489 France 1491 EMail: julien.bournelle@int-evry.fr 1493 Intellectual Property Statement 1495 The IETF takes no position regarding the validity or scope of any 1496 Intellectual Property Rights or other rights that might be claimed to 1497 pertain to the implementation or use of the technology described in 1498 this document or the extent to which any license under such rights 1499 might or might not be available; nor does it represent that it has 1500 made any independent effort to identify any such rights. Information 1501 on the procedures with respect to rights in RFC documents can be 1502 found in BCP 78 and BCP 79. 1504 Copies of IPR disclosures made to the IETF Secretariat and any 1505 assurances of licenses to be made available, or the result of an 1506 attempt made to obtain a general license or permission for the use of 1507 such proprietary rights by implementers or users of this 1508 specification can be obtained from the IETF on-line IPR repository at 1509 http://www.ietf.org/ipr. 1511 The IETF invites any interested party to bring to its attention any 1512 copyrights, patents or patent applications, or other proprietary 1513 rights that may cover technology that may be required to implement 1514 this standard. Please address the information to the IETF at 1515 ietf-ipr@ietf.org. 1517 Disclaimer of Validity 1519 This document and the information contained herein are provided on an 1520 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1521 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1522 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1523 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1524 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1525 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1527 Copyright Statement 1529 Copyright (C) The Internet Society (2004). This document is subject 1530 to the rights, licenses and restrictions contained in BCP 78, and 1531 except as set forth therein, the authors retain all their rights. 1533 Acknowledgment 1535 Funding for the RFC Editor function is currently provided by the 1536 Internet Society.