idnits 2.17.1 draft-bertz-dime-policygroups-03.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 (March 9, 2017) is 2576 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 M. Bales 4 Intended status: Standards Track Sprint 5 Expires: September 10, 2017 March 9, 2017 7 Diameter Policy Groups and Sets 8 draft-bertz-dime-policygroups-03 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 September 10, 2017. 32 Copyright Notice 34 Copyright (c) 2017 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 Policy applications often apply common policies to multiple 62 authorized users. Bulk operations are often applied through the use 63 of group naming, e.g. 3GPP's use of Base Name. 65 This document defines a grouping mechanism to apply common operations 66 to a group of policies and a membership set that can be used to 67 quickly apply one or more Diameter based policies, e.g. Filter-Rule 68 [RFC5777] to authorized users. 70 2. Requirements Language 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Terminology 78 Authorized Users An Entity that has been authorized to use a service 79 via a Diamater Application. 81 Base Name An organizational structure used to define a domain for 82 multiple Policy Groups or Membership Domains. 84 Determination Type The matching policy applied, e.g. ANDMASK, AND, 85 etc, for Membership Determination. 87 Policy Entity A type that may be assigned to a Policy Group or 88 Membership. This includes but is not limited to Filters [RFC7155] 89 or Filter-Rules [RFC5777]. 91 Membership Determination The process by which Policy Entities are 92 selected to be applied to an authorized User. 94 Membership Domain A name assigned to a Membership Set. 96 Membership Value A binary set of values where each bit represents a 97 specific membership pattern. 99 4. Concepts 101 Policy Groups represent a union of Policy Entities. These entities 102 MUST be of the same type, e.g. Filters [RFC7155] or Filter-Rules 103 [RFC5777]. 105 When establishing groups and membership Sets an optional Base Name 106 MAY be used. It identifies the top level grouping. Policy Entity 107 groups MAY be directly named as well. A Policy Entity's name MUST 108 contain zero or 1 separator character '/'. The value before the 109 separator is a Base Name. When no Base Name is provided, i.e. no 110 separator is present. The value of a policy entity is considered to 111 be part of the Base Name "" (empty string) for any matching purposes. 112 Base Name values MUST NOT contain the '/' character. 114 A Policy Entity can be applied to multiple, distinct sets of 115 authorized Users. These sets can be based upon their state (paid, 116 past due, etc.), customer type (pre-paid, post-paid, etc.) or many 117 other factors. In such cases, a Membership Domain is used. 119 Membership Domains are named domains (UTF8Strings) with binary values 120 stored in BitStrings to represent where the Policy Entity is used. A 121 Policy Entity MAY appear in multiple Membership Domains. 123 This mechanism creates a compact bit pattern to be used which notes 124 when a Policy Entity or Policy Group applies to to an Authorized 125 User. 127 An Authorized User's memberships are assigned by a Policy-Membership. 128 A Policy Entity is assigned membership via a Membership-Assignment. 129 Multiple assignments may be applied to an Authorized User and Policy 130 Entity but they MUST have unique Membership Domain values. It is 131 also RECOMMENDED to avoid numerous Policy-Membership assignments for 132 an Authorized User as it delays computation of the Policy Entities 133 that should be applied to their Service. 135 Memberships are matched by understanding the relationship between 136 their values which are represented as sets of bits. These 137 relationships are descibed as Match-Types and are specified as set 138 relations, e.g. subset, superset, etc. Figure 1 shows the reference 139 model. 141 0..1 +-----------+ 0..1 142 +------------->| Base-Name |<------------+ 143 | +-----+-----+ | 144 | 0..1 | +-----------+-----------+ 145 | | | Membership-Assignment | 146 | | +--------+--+-------+---+ 147 | | * ^ | | | 148 | * | | | | v 149 | +------+--------+ | | | +------------+ 150 | | Policy Entity +--+ | | | Match-Type | 151 | +---------------+ | | +------------+ 152 | | | 153 +---------+---------+0..1 +-----------------+ | | 154 | Policy-Membership |<-----+ Authorized User | | | 155 +-----+---+---------+ +-----------------+ | | 156 | | | | 157 | | 0..1+-------------------+ | | 158 | +------------>| Membership Domain |<--+ | 159 | +-------------------+ 0..1 | 160 v | 161 +------------------+ | 162 | Membership-Value |<------------------------------+ 163 +------------------+ 165 Figure 1: Reference Model 167 To determine if a Rule is assigned to the User the following 168 conditions MUST be true at least one Membership-Assignments must 169 exist where 171 Policy-Membership's Membership-Domain = Membership-Assignment's 172 Membership-Domain 174 Policy-Membership's Membership-Value MUST satisfy the Match-Type 175 for the Membership-Assignments' Membership-Value 177 5. Groups and Membership AVPs 179 5.1. Base-Name AVP 181 The Base-Name AVP (AVP Code TBD1) is of type UTF8String and defines a 182 group of Policy Entities, e.g. Filters [RFC7155] or Filter-Rules 183 [RFC5777]. 185 All Policy Entities with the same Base-Name MUST be of the same AVP 186 type. 188 A Base-Name MAY be assigned at the creation of the Policy Entity or 189 in a subsequent update but MUST only be assigned once, i.e. re- 190 assignment of the Base-Name MUST NOT be allowed. 192 5.2. Policy-Membership AVP 194 The Policy-Membership AVP (AVP Code TBD2) is of type Grouped and 195 specifies the Membership-Value and optionally the Membership-Domain 196 and Base-Name for an Authorized User. It is defined as follows (per 197 the grouped-avp-def of [RFC6733]): 199 Policy-Membership ::= < AVP Header: TBD2 > 200 { Membership-Value } 201 [ Membership-Domain ] 202 [ Base-Name ] 204 Multiple Policy-Membership values MAY be assigned to an Authorzied 205 User. However, assigning multiple Policy-Memberships to an 206 Authorized Users MAY delay policy enforcement as membership 207 determination time is increased and SHOULD be avoided. 209 If multiple Policy-Memberships are assigned to an Authorized User, 210 the Membership-Domain of each Policy-Membership value MUST be unique. 212 5.3. Membership-Assignment AVP 214 The Membership-Assignment AVP (AVP Code TBD3) is of type Grouped and 215 specifies the Membership-Value and optionally the Membership-Domain 216 and Base-Name for a Policy-Entity. It is defined as follows (per the 217 grouped-avp-def of [RFC6733]): 219 Membership-Assignment ::= < AVP Header: TBD3 > 220 { Membership-Value } 221 { Match-Type } 222 [ Membership-Domain ] 223 [ Base-Name ] 225 Multiple Policy-Membership values MAY be assigned to a Policy Entity. 226 If multiple Policy-Memberships are assigned, the Membership-Domain of 227 each Membership-Assignment MUST be unique. 229 5.4. Membership-Domain AVP 231 The Membership-Domain AVP (AVP Code TBD4) is of type UTF8String and 232 defines a membership set for a group of Policy Entities, e.g. 234 Filters [RFC7155] or Filter-Rules [RFC5777], that are commonly 235 applied to a set of Authorized Users. 237 5.5. Membership-Value AVP 239 The Membership-Value AVP (AVP Code TBD5) is of type OctetString and 240 defines a membership of a Policy Entity or Authorized User. 242 Each bit of the OctetString represents a single position in the 243 Membership-Domain set. 245 When two Membership-Values of different lengths are compared, the 246 smaller Membership-Value is padded with '0' valued bits until it is 247 the same length as the longer Membership-Value. 249 5.6. Match-Type AVP 251 The Match-Type AVP (AVP Code TBD6) is of type Enumerated and defines 252 the type of Matching algorithm used for the Policy Entity. 254 When applying the Match-Type between the Membership-Value of 255 Membership-Assignment (Policy Entity) and a Policy-Membership 256 (Authorized User), the Membership-Domain MUST be the same, i.e. they 257 are omitted or both MUST be present and have the same value. 259 Match-Types can be one of the following: 261 EQ 0 263 The Membership-Values are equal. 265 SUPER 1 267 The Membership-Assignment's Membership-Value is a superset of the 268 Policy-Membership's Membership-Value, i.e. the may be equal. 270 PSUPER 2 272 The Membership-Assignment's Membership-Value is a proper superset of 273 the Policy-Membership's Membership-Value. 275 SUB 3 277 The Membership-Assignment's Membership-Value is a subset of the 278 Policy-Membership's Membership-Value, i.e. the may be equal. 280 PSUB 4 281 The Membership-Assignment's Membership-Value is a proper subset of 282 the Policy-Membership's Membership-Value. 284 OVERLAP 5 286 The Membership-Assignment's Membership-Value has overlap with the 287 Policy-Membership's Membership-Value. They may be equal or have some 288 form of subset / superset relationship. 290 NONOVERLAP 6 292 The Membership-Assignment's Membership-Value has no intersection with 293 the Policy-Membership's Membership-Value. 295 6. Lifecycle Considerations 297 Base Names are typically assigned when a Policy Entity is installed 298 on the Diameter Client. Assignment MAY occur after installation but 299 the impact of this is outside of the scope of this document. 301 Membership-Assignments MAY occur at any time in the lifecycle of the 302 Policy Entity. However, there is no guarantee that resources exist 303 on the Diameter Client to perform a re-evualation of the membership 304 of all Authorized Users. A Diameter Server MUST NOT assume that re- 305 evaluation will occur or that an evaluation will occur immediately. 307 Policy-Memberships MAY change at any time in the lifecycle of the 308 Authorized User's session. It is expected that sufficient resources 309 exist to perform a re-evaluation of applicable Policy Entities based 310 upon Membership testing. If this cannot be done a Diameter 311 Applicaiton level appropriate message MUST be sent to the Diamater 312 Server. 314 Generally, Base-Names assignment SHOULD occur upon creation of a 315 Policy Entity or the authorization of a User. Membership-Assignments 316 SHOULD occur prior to an Authorized User being created with a Policy- 317 Membership that would apply the Policy Entity to the Authorized 318 User's session. 320 7. Examples 322 7.1. Rule Sets 324 A policy administrator has defined three 'default rule sets' based 325 upon various product options selected by a Customer. Each rule set 326 consists of twenty Filter-Rules as defined in [RFC5777]. 328 Rules that are part of Rule Set 1 are given a Membership-Value of 1, 329 Rule Set 2 members are given the value 2 and Rule Set three members 330 have a value of 4 in their respective Membership-Assignment values. 331 All Membership-Assignments have the Membership-Domain of "Product X" 332 and a Match-Type of EQ (Equals). 334 When a User is Authorized for service usage, a Policy-Membership 335 value is provided with the appropriate Membership-Value set to 1, 2 336 or 4 and a Membership-Domain of "Product X". The Diameter Client can 337 then appropriately the correct 20 Filter-Rules. 339 7.2. Rule in multiple sets (1 Domain) 341 Expanding upon our example from above Section 7.1, a new Filter-Rule 342 is added that is part of both Rule Set 1 and Rule Set 2. 344 According, the Membership-Assignment has a Membership-Domain of 345 "Product X", a Membership-Value of 3 and a Match-Type of OVERLAP. 346 Thus, any Policy-Membership whose Membership-Value is set to 1 or 2 347 will have this Filter-Rule applied. 349 7.3. Default Route (Overlapping) Rules 351 A common traffic rule is the default (all traffic) rule. It is often 352 used as the lowest priority rule in a policy enforcement session. 353 Even though the rule is typically the same, e.g. "any any", the 354 actions taken may vary, e.g. deny traffic, permit traffic, set 355 quality of service. To distinguish the rules the use of the 356 Membership-Domain in the Membership-Assignment even when the 357 Membership-Value MAY be the same. 359 8. IANA Considerations 361 IANA allocated AVP codes in the IANA-controlled namespace registry 362 specified in Section 11.1.1 of [RFC6733] for the following AVPs that 363 are defined in this document. 365 +-----------------------+----------+-----------------+-------------+ 366 | AVP | AVP Code | Section Defined | Data Type | 367 +-----------------------+----------+-----------------+-------------+ 368 | Base-Name | TBD1 | Section 5.1 | UTF8String | 369 | | | | | 370 | Policy-Membership | TBD2 | Section 5.2 | GROUPED | 371 | | | | | 372 | Membership-Assignment | TBD3 | Section 5.3 | GROUPED | 373 | | | | | 374 | Membership-Domain | TBD4 | Section 5.4 | UTF8String | 375 | | | | | 376 | Membership-Value | TBD5 | Section 5.5 | OctetString | 377 | | | | | 378 | Match-Type | TBD6 | Section 5.6 | Enumerated | 379 +-----------------------+----------+-----------------+-------------+ 381 9. Security Considerations 383 The use of Base-Names and Membership-Domain can unintentionally 384 provide user information if it is too explicit, e.g. "Bobs' 385 Policies". It is RECOMMENDED that an operator consider the values it 386 assigns and ensure they provide no user or group speicific 387 information. 389 As bit and test patterns the data provided by the Membership- 390 Assignment and Policy-Membership AVPs provide more clues between an 391 Operator and Authorized User's policy relationship. However, it is 392 no different than if one has access to the information transmitted 393 between the Diameter Client and Server today (if the Base-Names and 394 Membership-Domains) follow the reommendations in this section. 396 In either case, access to the Diameter communications is still 397 required. 399 The Security Considerations of the Diameter protocol itself have been 400 discussed in [RFC6733]. The Diameter base protocol [RFC6733] 401 requires that each Diameter implementation use underlying security; 402 i.e., TLS/TCP, DTLS/SCTP or IPsec. Use of the AVPs defined in this 403 document MUST take into consideration the security issues and 404 requirements of the Diameter base protocol. 406 10. References 408 10.1. Normative References 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, 412 DOI 10.17487/RFC2119, March 1997, 413 . 415 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 416 Ed., "Diameter Base Protocol", RFC 6733, 417 DOI 10.17487/RFC6733, October 2012, 418 . 420 10.2. Informative References 422 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 423 Ed., and A. Lior, "Traffic Classification and Quality of 424 Service (QoS) Attributes for Diameter", RFC 5777, 425 DOI 10.17487/RFC5777, February 2010, 426 . 428 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 429 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 430 . 432 Authors' Addresses 434 Lyle Bertz 435 Sprint 436 6220 Sprint Parkway 437 Overland Park, KS 66251 438 United States 440 Email: lylebe551144@gmail.com 442 Mark Bales 443 Sprint 444 6220 Sprint Parkway 445 Overland Park, KS 66251 446 United States 448 Email: yellowjeep2017@gmail.com