idnits 2.17.1 draft-bertz-dime-policygroups-06.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 (June 18, 2018) is 2139 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: December 20, 2018 June 18, 2018 7 Diameter Policy Groups and Sets 8 draft-bertz-dime-policygroups-06 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 https://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 December 20, 2018. 32 Copyright Notice 34 Copyright (c) 2018 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 (https://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 As Users connect to a network, policy applications often apply common 62 policies to them. In some cases policies are grouped and applied 63 through the use of AVPs, e.g. 3GPP Base Name. Other options include 64 sending identifiers, usually a list of integers, associated with 65 rules to apply a group to a single user. This compacts the over the 66 wire representation but requires strong coordination between policy 67 based Clients and Servers. 69 Application of common policy if further limited when the filters 70 overlap. This requires partitioning policies into non-overlapping 71 namespaces, e.g. tables in a Software Defined Networking (SDN) 72 switch. To reduce the need to partition sets of policies some SDN 73 technologies, e.g. OpenFlow, rely on metadata that is applied as 74 part of the filter or metadata that is specific to the packet, e.g. 75 OpenFlow Registers. 77 This document defines grouping mechanisms to allow users or groups of 78 users to share policies or groups of policies. The mechanism also 79 extends filters to include a metadata matching field that permits 80 filters that overlap at the protocol level to coexist in the same 81 policy enforcement space. 83 2. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. Terminology 91 Authorized Users An Entity that has been authorized to use a service 92 via a Diameter Application. 94 Base Name An organizational structure used to define a domain for 95 multiple Policy Groups or Membership Domains. 97 Determination Type The matching policy applied, e.g. ANDMASK, AND, 98 etc, for Membership Determination. 100 Policy Entity A type that may be assigned to a Policy Group or 101 Membership. This includes but is not limited to Filters [RFC7155] 102 or Filter-Rules [RFC5777]. 104 Membership Determination The process by which Policy Entities are 105 selected to be applied to an authorized User. 107 Membership Domain A name assigned to a Membership Set. 109 Membership Value A binary set of values where each bit represents a 110 specific membership pattern. This metadata is used as part of the 111 filter or as user information when policy application occurs. 113 4. Concepts 115 Policy Groups represent a union of Policy Entities. These entities 116 MUST be of the same type, e.g. Filters [RFC7155] or Filter-Rules 117 [RFC5777]. 119 When establishing groups and membership Sets an optional Base Name 120 MAY be used. It identifies the top level grouping. Policy Entity 121 groups MAY be directly named as well. A Policy Entity's name MUST 122 contain zero or 1 separator character '/'. The value before the 123 separator is a Base Name. When no Base Name is provided, i.e. no 124 separator is present. The value of a policy entity is considered to 125 be part of the Base Name "" (empty string) for any matching purposes. 126 Base Name values MUST NOT contain the '/' character. 128 A Policy Entity can be applied to multiple, distinct sets of 129 authorized Users. These sets can be based upon their state (paid, 130 past due, etc.), customer type (pre-paid, post-paid, etc.) or many 131 other factors. In such cases, a Membership Domain is used. 133 Membership Domains are named domains (UTF8Strings) with binary values 134 stored in bit strings to represent where the Policy Entity is used. 135 A Policy Entity MAY appear in multiple Membership Domains. 137 Membership-Value is a compact bit pattern to be used which notes when 138 a Policy Entity or Policy Group applies to to an Authorized User. 140 An Authorized User's memberships are assigned by a Policy-Membership. 141 A Policy Entity is assigned membership via a Membership-Assignment. 142 Multiple assignments may be applied to an Authorized User and Policy 143 Entity but they MUST have unique Membership Domain values. It is 144 also RECOMMENDED to avoid numerous Policy-Membership assignments for 145 an Authorized User as it delays computation of the Policy Entities 146 that should be applied to their service. 148 Memberships are matched by understanding the relationship between 149 their values which are represented as sets of bits. These 150 relationships are described as Match-Types and are specified as set 151 relations, e.g. subset, superset, etc. Figure 1 shows the reference 152 model. 154 0..1 +-----------+ 0..1 155 +------------->| Base-Name |<------------+ 156 | +-----+-----+ | 157 | 0..1 | +-----+-----------------+ 158 | | | Membership-Assignment | 159 | | +------------+--+-------+ 160 | | * ^ | | | 161 | * | | | | v 162 | +------+--------+ | | | +------------+ 163 | | Policy Entity +----+ | | | Match-Type | 164 | +---------------+ | | +------------+ 165 | | | 166 +---------+---------+0..1 +-----------------+ | | 167 | Policy-Membership |<-----+ Authorized User | | | 168 +---------+---------+ +-----------------+ | | 169 | | | | 170 | | 0..1+-------------------+ | | 171 | +------------>| Membership Domain |<--+ | 172 | +-------------------+ 0..1 | 173 v | 174 +------------------+ | 175 | Membership-Value |<------------------------------+ 176 +------------------+ 178 Figure 1: Reference Model 180 To determine if a Rule is assigned to the User the following 181 conditions MUST be true at least one Membership-Assignments must 182 exist where 184 Policy-Membership's Membership-Domain = Membership-Assignment's 185 Membership-Domain 187 Policy-Membership's Membership-Value MUST satisfy the Match-Type 188 for the Membership-Assignments' Membership-Value 190 5. Groups and Membership AVPs 192 5.1. Base-Name AVP 194 The Base-Name AVP (AVP Code TBD1) is of type UTF8String and defines a 195 group of Policy Entities, e.g. Filters [RFC7155] or Filter-Rules 196 [RFC5777]. 198 All Policy Entities with the same Base-Name MUST be of the same AVP 199 type. 201 A Base-Name MAY be assigned at the creation of the Policy Entity or 202 in a subsequent update but MUST only be assigned once, i.e. re- 203 assignment of the Base-Name MUST NOT be allowed. 205 5.2. Policy-Membership AVP 207 The Policy-Membership AVP (AVP Code TBD2) is of type Grouped and 208 specifies the Membership-Value and optionally the Membership-Domain 209 and Base-Name for an Authorized User. It is defined as follows (per 210 the grouped-avp-def of [RFC6733]): 212 Policy-Membership ::= < AVP Header: TBD2 > 213 { Membership-Value } 214 [ Membership-Domain ] 215 [ Base-Name ] 217 Multiple Policy-Membership values MAY be assigned to an Authorized 218 User. However, assigning multiple Policy-Memberships to an 219 Authorized Users MAY delay policy enforcement as membership 220 determination time is increased and SHOULD be avoided. 222 If multiple Policy-Memberships are assigned to an Authorized User, 223 the Membership-Domain of each Policy-Membership value MUST be unique. 225 5.3. Membership-Assignment AVP 227 The Membership-Assignment AVP (AVP Code TBD3) is of type Grouped and 228 specifies the Membership-Value and optionally the Membership-Domain 229 and Base-Name for a Policy-Entity. It is defined as follows (per the 230 grouped-avp-def of [RFC6733]): 232 Membership-Assignment ::= < AVP Header: TBD3 > 233 { Membership-Value } 234 { Match-Type } 235 [ Membership-Domain ] 236 [ Base-Name ] 238 Multiple Policy-Membership values MAY be assigned to a Policy Entity. 239 If multiple Policy-Memberships are assigned, the Membership-Domain of 240 each Membership-Assignment MUST be unique. 242 5.4. Membership-Domain AVP 244 The Membership-Domain AVP (AVP Code TBD4) is of type UTF8String and 245 defines a membership set for a group of Policy Entities, e.g. 246 Filters [RFC7155] or Filter-Rules [RFC5777], that are commonly 247 applied to a set of Authorized Users. 249 5.5. Membership-Value AVP 251 The Membership-Value AVP (AVP Code TBD5) is of type OctetString and 252 defines a membership of a Policy Entity or Authorized User. 254 Each bit of the OctetString represents a single position in the 255 Membership-Domain set. 257 When two Membership-Values of different lengths are compared, the 258 smaller Membership-Value is padded with '0' valued bits until it is 259 the same length as the longer Membership-Value. 261 5.6. Match-Type AVP 263 The Match-Type AVP (AVP Code TBD6) is of type Enumerated and defines 264 the type of Matching algorithm used for the Policy Entity. 266 When applying the Match-Type between the Membership-Value of 267 Membership-Assignment (Policy Entity) and a Policy-Membership 268 (Authorized User), the Membership-Domain MUST be the same, i.e. they 269 are omitted or both MUST be present and have the same value. 271 Match-Types can be one of the following: 273 EQ 0 275 The Membership-Values are equal. 277 SUPER 1 278 The Membership-Assignment's Membership-Value is a superset of the 279 Policy-Membership's Membership-Value, i.e. the may be equal. 281 PSUPER 2 283 The Membership-Assignment's Membership-Value is a proper superset of 284 the Policy-Membership's Membership-Value. 286 SUB 3 288 The Membership-Assignment's Membership-Value is a subset of the 289 Policy-Membership's Membership-Value, i.e. the may be equal. 291 PSUB 4 293 The Membership-Assignment's Membership-Value is a proper subset of 294 the Policy-Membership's Membership-Value. 296 OVERLAP 5 298 The Membership-Assignment's Membership-Value has overlap with the 299 Policy-Membership's Membership-Value. They may be equal or have some 300 form of subset / superset relationship. 302 NONOVERLAP 6 304 The Membership-Assignment's Membership-Value has no intersection with 305 the Policy-Membership's Membership-Value. 307 6. Lifecycle Considerations 309 Base Names are typically assigned when a Policy Entity is installed 310 on the Diameter Client. Assignment MAY occur after installation but 311 the impact of this is outside of the scope of this document. 313 Membership-Assignments MAY occur at any time in the lifecycle of the 314 Policy Entity. However, there is no guarantee that resources exist 315 on the Diameter Client to perform a re-evaluation of the membership 316 of all Authorized Users. A Diameter Server MUST NOT assume that re- 317 evaluation will occur or that an evaluation will occur immediately. 319 Policy-Memberships MAY change at any time in the lifecycle of the 320 Authorized User's session. It is expected that sufficient resources 321 exist to perform a re-evaluation of applicable Policy Entities based 322 upon Membership testing. If this cannot be done a Diameter 323 Application level appropriate message MUST be sent to the Diameter 324 Server. 326 Generally, Base-Name assignment SHOULD occur upon creation of a 327 Policy Entity or the authorization of a User. Membership-Assignments 328 SHOULD occur prior to an Authorized User being created with a Policy- 329 Membership that would apply the Policy Entity to the Authorized 330 User's session. 332 7. Examples 334 7.1. Rule Sets 336 A policy administrator defines Product X with 3 separate rules sets. 337 The administrator creates the Membership-Domain "Product X" and 338 Membership-Values of 1, 2 and 4 representing separate rule sets. For 339 this example each rule set consists of twenty Filter-Rules as defined 340 in [RFC5777]. 342 Each Rule Set is assigned a Membership-Value. Rule Set 1 is assigned 343 a Membership-Value of 1, Rule Set 2 members is assigned the value 2 344 and Rule Set three members are assigned a value of 4. All 345 Membership-Assignments have the Membership-Domain of "Product X" and 346 a Match-Type of EQ (Equals). 348 The policy administrator defines three users. User 1 is assigned the 349 Membership-Domain of "Product X"" and Membership-Value of 1. User 2 350 is assigned a Membership-Domain of "Product X" and a Membership-Value 351 of 2. User 3 is assigned a Membership-Domain of "Product X"" and 352 Membership-Value of 4. 354 7.2. Rule in multiple sets (1 Domain) 356 Expanding upon our example from above Section 7.1, a new Filter-Rule 357 is added that shall be part of Users with either Rule Set 1 or Rule 358 Set 2 of Product X. 360 Accordingly, the policy administrator defines the Membership- 361 Assignment having a Membership-Domain of "Product X", a Membership- 362 Value of 3 and a Match-Type of OVERLAP. Thus, any Policy-Membership 363 whose Membership-Value is set to 1 or 2 will have this Filter-Rule 364 applied. 366 7.3. Default Route (Overlapping) Rules 368 A common traffic rule is the default (all traffic) rule. It is often 369 used as the lowest priority rule in a policy enforcement session. 370 Even though the rule is typically the same, e.g. "any any", the 371 actions taken may vary, e.g. deny traffic, permit traffic, set 372 quality of service. To distinguish the rules the use of the 373 Membership-Domain in the Membership-Assignment even when the 374 Membership-Value MAY be the same. 376 Within the enforcement point, for each overlapping Match-Type can be 377 set to OVERLAP and contain all bits where the rule applies in its 378 Membership-Value. In general, the Membership-Value MUST be NOT 379 overlap with other default rules or a Precedence MUST be followed. 381 In the case where a Filter-Rule [RFC5777] is used, the Match-Type and 382 Membership-Value can be used as part of the Classifier AVP. 384 8. IANA Considerations 386 IANA allocated AVP codes in the IANA-controlled namespace registry 387 specified in Section 11.1.1 of [RFC6733] for the following AVPs that 388 are defined in this document. 390 +-----------------------+----------+-----------------+-------------+ 391 | AVP | AVP Code | Section Defined | Data Type | 392 +-----------------------+----------+-----------------+-------------+ 393 | Base-Name | TBD1 | Section 5.1 | UTF8String | 394 | | | | | 395 | Policy-Membership | TBD2 | Section 5.2 | GROUPED | 396 | | | | | 397 | Membership-Assignment | TBD3 | Section 5.3 | GROUPED | 398 | | | | | 399 | Membership-Domain | TBD4 | Section 5.4 | UTF8String | 400 | | | | | 401 | Membership-Value | TBD5 | Section 5.5 | OctetString | 402 | | | | | 403 | Match-Type | TBD6 | Section 5.6 | Enumerated | 404 +-----------------------+----------+-----------------+-------------+ 406 9. Security Considerations 408 The use of Base-Names and Membership-Domain can unintentionally 409 provide user information if it is too explicit, e.g. "Bobs' 410 Policies". It is RECOMMENDED that an operator consider the values it 411 assigns and ensure they provide no user or group specific 412 information. 414 As bit and test patterns the data provided by the Membership- 415 Assignment and Policy-Membership AVPs provide more clues between an 416 Operator and Authorized User's policy relationship. However, it is 417 no different than if one has access to the information transmitted 418 between the Diameter Client and Server today (if the Base-Names and 419 Membership-Domains) follow the recommendations in this section. 421 In either case, access to the Diameter communications is still 422 required. 424 The Security Considerations of the Diameter protocol itself have been 425 discussed in [RFC6733]. The Diameter base protocol [RFC6733] 426 requires that each Diameter implementation use underlying security; 427 i.e., TLS/TCP, DTLS/SCTP or IPsec. Use of the AVPs defined in this 428 document MUST take into consideration the security issues and 429 requirements of the Diameter base protocol. 431 10. References 433 10.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 441 Ed., "Diameter Base Protocol", RFC 6733, 442 DOI 10.17487/RFC6733, October 2012, 443 . 445 10.2. Informative References 447 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., 448 Ed., and A. Lior, "Traffic Classification and Quality of 449 Service (QoS) Attributes for Diameter", RFC 5777, 450 DOI 10.17487/RFC5777, February 2010, 451 . 453 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 454 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 455 . 457 Authors' Addresses 459 Lyle Bertz 460 Sprint 461 6220 Sprint Parkway 462 Overland Park, KS 66251 463 United States 465 Email: lylebe551144@gmail.com 466 Mark Bales 467 Sprint 468 6220 Sprint Parkway 469 Overland Park, KS 66251 470 United States 472 Email: yellowjeep2017@gmail.com