idnits 2.17.1 draft-bertz-dime-policygroups-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2016) is 2851 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions L. Bertz 3 Internet-Draft Sprint 4 Intended status: Standards Track July 6, 2016 5 Expires: January 7, 2017 7 Diameter Policy Groups and Sets 8 draft-bertz-dime-policygroups-00 10 Abstract 12 This document defines optional Diameter attributes for efficient 13 policy provisioning. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 7, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 1. Introduction 61 Quite often policy applications will apply common policies over 62 multiple authorized endpoints. These policies may be pre-provisioned 63 or dynamically installed on the Diamater Client by the Diamater 64 Server. 66 Techniques such as policy grouping, e.g. Base Name used in many 3GPP 67 specifications or Bit Set values are applied. 69 This document defines both a grouping mechanism, the Group-Name AVP, 70 and a membership (bit set) that can be used to quickly apply one or 71 more Diameter based policies, e.g. Filter-Rule [RFC5777]. 73 2. Requirements Language 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 3. Terminology 81 Authorized Users An Entity that has been authorized to use a service 82 via a Diamater Application. 84 Base Name An organizational structure used to define a domain for 85 multiple Policy Groups or Membership Domains. 87 Determination Type The matching policy applied, e.g. ANDMASK, AND, 88 etc, for Membership Determination. 90 Policy Entity A type that may be assigned to a Policy Group or 91 Membership. This includes but is not limited to Filters [RFC7155] 92 or Filter-Rules [RFC5777]. 94 Membership Determination The process by which Policy Entities are 95 selected to be applied to an authorized User. 97 Membership Domain A name assigned to a Membership Set. 99 Membership Value A binary set of values where each bit represents a 100 specific membership pattern. 102 4. Concepts 104 Policy Groups represent a union of Policy Entities. These entities 105 MUST be of the same type, e.g. Filters [RFC7155] or Filter-Rules 106 [RFC5777]. 108 When establishing groups and membership Sets an optional Base Name 109 MAY be used. It identifies the top level grouping. Policy Entity 110 groups MAY be directly named as well. When no Base Name is provided 111 the value a policy entity is considered to be part of the Base Name 112 "" (empty string) for any matching purposes. 114 Base Name values create a two tier heirarchy for grouping. However, 115 a Policy Entity can be applied to multiple, distinct sets of 116 authorized Users. These sets can be based upon their state (paid, 117 past due, etc.), customer type (pre-paid, post-paid, etc.) or many 118 other factors. In such cases, a Membership Domain is used. 120 Membership Domains are named domains (UTF8Strings) with binary values 121 stored in BitStrings to represent where the Policy Entity is used. A 122 Policy Entity MAY appear in multiple Membership Domains. 124 This mechanism creates a compact bit pattern to be used which notes 125 when a Policy Entity or Policy Group applies to to an Authorized 126 User. 128 5. Groups and Membership AVPs 130 5.1. Base-Name AVP 132 The Base-Name AVP (AVP Code TBD1) is of type UTF8String and defines a 133 group of Policy Entities, e.g. Filters [RFC7155] or Filter-Rules 134 [RFC5777]. 136 All Policy Entities with the same Base-Name MUST be of the same AVP 137 type. 139 A Base-Name MAY be assigned at the creation of the Policy Entity or 140 in a subsequent update but MUST only be assigned once, i.e. re- 141 assignment of the Base-Name MUST NOT be allowed. 143 5.2. Policy-Membership AVP 145 The Policy-Membership AVP (AVP Code TBD2) is of type Grouped and 146 specifies the Membership-Value and optionally the Membership-Domain 147 and Base-Name for an Authorized User. It is defined as follows (per 148 the grouped-avp-def of [RFC6733]): 150 Policy-Membership ::= < AVP Header: TBD2 > 151 { Membership-Value } 152 [ Membership-Domain ] 153 [ Base-Name ] 155 Multiple Policy-Membership values MAY be assigned to an Authorzied 156 User. However, assigning multiple Policy-Memberships to an 157 Authorized Users MAY delay policy enforcement as membership 158 determination time is increased and SHOULD be avoided. 160 If multiple Policy-Memberships are assigned to an Authorized User, 161 the Membership-Domain of each Policy-Membership value MUST be unique. 163 5.3. Membership-Assignment AVP 165 The Membership-Assignment AVP (AVP Code TBD3) is of type Grouped and 166 specifies the Membership-Value and optionally the Membership-Domain 167 and Base-Name for a Policy-Entity. It is defined as follows (per the 168 grouped-avp-def of [RFC6733]): 170 Membership-Assignment ::= < AVP Header: TBD3 > 171 { Membership-Value } 172 { Match-Type } 173 [ Membership-Domain ] 174 [ Base-Name ] 176 Multiple Policy-Membership values MAY be assigned to a Policy Entity. 177 If multiple Policy-Memberships are assigned, the Membership-Domain of 178 each Membership-Assignment MUST be unique. 180 5.4. Membership-Domain AVP 182 The Membership-Domain AVP (AVP Code TBD4) is of type UTF8String and 183 defines a membership set for a group of Policy Entities, e.g. 184 Filters [RFC7155] or Filter-Rules [RFC5777], that are commonly 185 applied to a set of Authorized Users. 187 5.5. Membership-Value AVP 189 The Membership-Value AVP (AVP Code TBD5) is of type OctetString and 190 defines a membership of a Policy Entity or Authorized User. 192 Each bit of the OctetString represents a single position in the 193 Membership-Domain set. 195 When two Membership-Values of different lengths are compared, the 196 smaller Membership-Value is padded with '0' valued bits until it is 197 the same length as the longer Membership-Value. 199 5.6. Match-Type AVP 201 The Match-Type AVP (AVP Code TBD6) is of type Enumerated and defines 202 the type of Matching algorithm used for the Policy Entity. 204 When applying the Match-Type between the Membership-Value of 205 Membership-Assignment (Policy Entity) and a Policy-Membership 206 (Authorized User), the Membership-Domain MUST be the same, i.e. they 207 are omitted or both MUST be present and have the same value. 209 Match-Types can be one of the following: 211 EQ 0 213 The Membership-Values are equal. 215 SUPER 1 217 The Membership-Assignment's Membership-Value is a superset of the 218 Policy-Membership's Membership-Value, i.e. the may be equal. 220 PSUPER 2 222 The Membership-Assignment's Membership-Value is a proper superset of 223 the Policy-Membership's Membership-Value. 225 SUB 3 227 The Membership-Assignment's Membership-Value is a subset of the 228 Policy-Membership's Membership-Value, i.e. the may be equal. 230 PSUB 4 232 The Membership-Assignment's Membership-Value is a proper subset of 233 the Policy-Membership's Membership-Value. 235 OVERLAP 5 237 The Membership-Assignment's Membership-Value has overlap with the 238 Policy-Membership's Membership-Value. They may be equal or have some 239 form of subset / superset relationship. 241 NONOVERLAP 6 243 The Membership-Assignment's Membership-Value has no intersection with 244 the Policy-Membership's Membership-Value. 246 6. Lifecycle Considerations 248 Base Names are typically assigned when a Policy Entity is installed 249 on the Diameter Client. Assignment MAY occur after installation but 250 the impact of this is outside of the scope of this document. 252 Membership-Assignments MAY occur at any time in the lifecycle of the 253 Policy Entity. However, there is no guarantee that resources exist 254 on the Diameter Client to perform a re-evualation of the membership 255 of all Authorized Users. A Diameter Server MUST NOT assume that re- 256 evaluation will occur or that an evaluation will occur immediately. 258 Policy-Memberships MAY change at any time in the lifecycle of the 259 Authorized User's session. It is expected that sufficient resources 260 exist to perform a re-evaluation of applicable Policy Entities based 261 upon Membership testing. If this cannot be done a Diameter 262 Applicaiton level appropriate message MUST be sent to the Diamater 263 Server. 265 Generally, Base-Names assignment SHOULD occur upon creation of a 266 Policy Entity or the authorization of a User. Membership-Assignments 267 SHOULD occur prior to an Authorized User being created with a Policy- 268 Membership that would apply the Policy Entity to the Authorized 269 User's session. 271 7. Example 273 7.1. Rule Sets 275 A policy administrator has defined three 'default rule sets' based 276 upon various product options selected by a Customer. Each rule set 277 consists of twenty Filter-Rules as defined in [RFC5777]. 279 Rules that are part of Rule Set 1 are given a Membership-Value of 1, 280 Rule Set 2 members are given the value 2 and Rule Set three members 281 have a value of 4 in their respective Membership-Assignment values. 283 All Membership-Assignments have the Membership-Domain of "Product X" 284 and a Match-Type of EQ (Equals). 286 When a User is Authorized for service usage, a Policy-Membership 287 value is provided with the appropriate Membership-Value set to 1, 2 288 or 4 and a Membership-Domain of "Product X". The Diameter Client can 289 then appropriately the correct 20 Filter-Rules. 291 7.2. Rule in multiple sets (1 Domain) 293 Expanding upon our example from above Section 7.1, a new Filter-Rule 294 is added that is part of both Rule Set 1 and Rule Set 2. 296 According, the Membership-Assignment has a Membership-Domain of 297 "Product X", a Membership-Value of 3 and a Match-Type of OVERLAP. 298 Thus, any Policy-Membership whose Membership-Value is set to 1 or 2 299 will have this Filter-Rule applied. 301 7.3. IANA Considerations 303 IANA allocated AVP codes in the IANA-controlled namespace registry 304 specified in Section 11.1.1 of [RFC6733] for the following AVPs that 305 are defined in this document. 307 +-----------------------+----------+-----------------+-------------+ 308 | AVP | AVP Code | Section Defined | Data Type | 309 +-----------------------+----------+-----------------+-------------+ 310 | Base-Name | TBD1 | Section 5.1 | UTF8String | 311 | | | | | 312 | Policy-Membership | TBD2 | Section 5.2 | GROUPED | 313 | | | | | 314 | Membership-Assignment | TBD3 | Section 5.3 | GROUPED | 315 | | | | | 316 | Membership-Domain | TBD4 | Section 5.4 | UTF8String | 317 | | | | | 318 | Membership-Value | TBD5 | Section 5.5 | OctetString | 319 | | | | | 320 | Match-Type | TBD6 | Section 5.6 | Enumerated | 321 +-----------------------+----------+-----------------+-------------+ 323 7.4. Security Considerations 325 The use of Base-Names and Membership-Domain can unintentionally 326 provide user information if it is too explicit, e.g. "Bobs' 327 Policies". It is RECOMMENDED that an operator consider the values it 328 assigns and ensure they provide no user or group speicific 329 information. 331 As bit and test patterns the data provided by the Membership- 332 Assignment and Policy-Membership AVPs provide more clues between an 333 Operator and Authorized User's policy relationship. However, it is 334 no different than if one has access to the information transmitted 335 between the Diameter Client and Server today (if the Base-Names and 336 Membership-Domains) follow the reommendations in this section. 338 In either case, access to the Diameter communications is still 339 required. 341 The Security Considerations of the Diameter protocol itself have been 342 discussed in [RFC6733]. The Diameter base protocol [RFC6733] 343 requires that each Diameter implementation use underlying security; 344 i.e., TLS/TCP, DTLS/SCTP or IPsec. Use of the AVPs defined in this 345 document MUST take into consideration the security issues and 346 requirements of the Diameter base protocol. 348 8. References 350 8.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 358 Ed., "Diameter Base Protocol", RFC 6733, 359 DOI 10.17487/RFC6733, October 2012, 360 . 362 8.2. Informative References 364 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 365 Ed., and A. Lior, "Traffic Classification and Quality of 366 Service (QoS) Attributes for Diameter", RFC 5777, 367 DOI 10.17487/RFC5777, February 2010, 368 . 370 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 371 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 372 . 374 Author's Address 375 Lyle Bertz 376 Sprint 377 6220 Sprint Parkway 378 Overland Park, KS 66251 379 United States 381 Email: lylebe551144@gmail.com